Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "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!8 -
I wonder if someone ever did the //TODOs or fixed the //FIXMEs I left in the code the last place I worked at 🤔7
-
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 release2 -
/**
* @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.1 -
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.3 -
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