// FIXME

So yesterday my girlfriend and me wanted to clean the apartment.

We ended up coding on a private project all day long... but at least we put //FIXME notes all over our place.

Let's see how today goes. ^^

Testing a raspberry pi 4 as a computer driving our 4k dashboards' screen. Temperatures are constantly 80-90C.

Me: STEP ASIDE! MAKE WAY FOR A HOTFIX!

Rpi: aaahhh, 42C -- now we're talkin!

//TODO:
//FIXME:
//BROKEN:

All of those will never ever be removed.
Ever...

I wonder if someone ever did the //TODOs or fixed the //FIXMEs I left in the code the last place I worked at 🤔

// FIXME
Never gets fixed.

Checkin into old projects be like..😵

Going through a startup code
...
// TODO: implement!
...
// FIXME: this is so messed up
...
...
// HACK: works for now, find a better way
...
// HACK: hardcoded for now
...
// FIXME: this doesn't work, crash here
...
...
// TODO: this probably should be a separate class
...
// TODO: change messed up variable names
...
// FIXME: WTF is this, Dave?!
...
...
// TODO: remove this before release

Instead of ;
I end lines with ; //FIXME

Stop commenting out code blocks!

Either fix your shit or delete it.

I am open to argue what fixing may mean, as it is perfectly fine to make your broken code not reachable, e.g. via feature flags or skipping certain tests. Yet never ever should you comment those blocks!

So you say you want to keep it for historic reasons? You know, that is why we use version control! If you ever need certain functionality back, you can restore that state.

Each decent IDE also offers a local history where you can even restore code blocks that weren't even pushed or committed. So use that!

Commenting out test cases is a really bad habit, as you have no reminder that you shall restore it.

And no, a TODO and a FIXME won't count as a reminder as you have to actively look for them. And we all know how well that goes, don't we? (One time, I found a typo of a `TDO`. So even with a regular lookup for TODO, stuff will slip.)

Each test suite offers you ways to skip tests if there are valid reasons why they should not fail the build temporary and they offer colorful feedback. Yes, that means that your tests won't be green, but guess what: That's a feature! They shouldn't be.

That yellow is a fine reminder, aka warning!, that you should really fix your shit.

Commented code screams: "I DON'T KNOW WHAT I WAS DOING!" and it confuses the hell out of other developers ("Was this commented because of debugging purposes and should be active again or can I safely delete this!?") and adds verbose crap to the code base.

If you find yourself to be in a place that you comment code a lot, I also argue that your workflow is broken.

When you are using a decent debugger, there shouldn't that much of a need to comment in and out a lot of code in order to reason about your code-base.

// TODO
// FIXME

Having these everywhere...

/**
* @fixme Properly escape this input, but for now str_replace(); will do.
*/

Ah, the good permanent temporary solutions.

fyi. The file in question has been untouched for 3-4 years.

I have a confession: I produced a shit ton of wacky code...

The business guy in my team is super fucking bitchy about deploying to prod, while my codebase is a total mess. I could refactor it to use a much cleaner module, but I had to do it because we're running out of time. I spent half a day trying to refactor while failing miserably.

//FIXME: I will come back... or not.

sometimes I'd like to put a "//FIXME" on people for the big developer in heaven...

git commit -m "FIXME: [bug description]

I do this only on my own projects, because even though the code is buggy, it's better to be able to com back to a less buggy version than to have to choose between a way to old version and an even worse version, after I introduced some more bugs

FIXME: Not for production!

// FIXME: work();

Forgot to put tags on my rant and now i cant modify it