2 ms·

"Broken code" "deployed" inside an `if (false) {}` (or even an `#if FALSE #endif` depending on your language of choice) isn't that much more of a footgun than a

"Broken code" "deployed" inside an `if (false) {}` (or even an `#if FALSE #endif` depending on your language of choice) isn't that much more of a footgun than a git branch hundreds of commits behind and full of merge issues. It's something of a "different strokes" preference and it's something of a question of how fast the main branch is moving and how hard to keep up with it. Most language compilers and JITs eliminate the unreachable code within a constant false branch sooner or later and the code isn't even technically "deployed" even though it exists in source control for that deployment.

wrsh07 3y ago
I would strongly recommend learning git basics! My branches are never more than a day behind main (rebase does wonders!) Code inside an if false block might as well be commented, and commented code is the fastest to bitrot - I would strongly recommend against!
- WorldMaker 3y ago
  There's still a difference between commented code because it is dead and bitrot and code-in-progress. I am among the first people to delete commented code and send anyone looking for it to git tutorials, but I've also kept git branches short by keeping code behind if flags (that are false in builds/production) while working on it so that I can still give that code the benefit of other refactors or compile errors and so that other developers are aware of that partially complete code. It's not a dichotomy, it's an orthogonal spectrum. Of course it is hugely useful to be good at source control. Of course it is still sometimes useful to have code compiling in CI/CD that "isn't ready yet" but prone to cross-fire in other on going work and refactoring. (Plus source control is greatly useful for answering "Why is this flag false right now? Who was last working on it and for what project?" and keeping that code honest that it isn't just bit rot.)

wrsh07 3y ago

I would strongly recommend learning git basics! My branches are never more than a day behind main (rebase does wonders!) Code inside an if false block might as well be commented, and commented code is the fastest to bitrot - I would strongly recommend against!

WorldMaker 3y ago
There's still a difference between commented code because it is dead and bitrot and code-in-progress. I am among the first people to delete commented code and send anyone looking for it to git tutorials, but I've also kept git branches short by keeping code behind if flags (that are false in builds/production) while working on it so that I can still give that code the benefit of other refactors or compile errors and so that other developers are aware of that partially complete code. It's not a dichotomy, it's an orthogonal spectrum. Of course it is hugely useful to be good at source control. Of course it is still sometimes useful to have code compiling in CI/CD that "isn't ready yet" but prone to cross-fire in other on going work and refactoring. (Plus source control is greatly useful for answering "Why is this flag false right now? Who was last working on it and for what project?" and keeping that code honest that it isn't just bit rot.)