Would you mind elaborating on this? As a newcomer to C style languages, I fail to see the upside here. Most editors have a built-in keystroke for commenting out a line or block of code, whereas your suggestion would require either making macros for every language you work with, or doing it manually every time.
What am I missing? Is there an extra compilation cost or something? 
Itâs a terrible suggestion necessitated by Zig intransigence of having both 1) unused variables being errors and 2) reused/aliased variables being compile errors even in debug modes. The consequence is that âcommentingâ out lines can give you a program that wonât compile because you took away the only usage of a variable even if the program is otherwise valid.
The fact that you have to resort to creating this kind of line noise (effectively requiring parseable comments 
) in your program just like is needed in C/C++ with (#if 0/#endif) should be something that should be a cautionary tale to Zig and not something to be emulated.
A lot of us just hold our noses and work around negatives like this and use Zig anyway because the positives outweigh them.
Oh, is that all?
Call it Stockholm Syndrome, but Iâm so used to that happening in other languages, Iâm not that bothered. Canât remember which langs at the moment tho, go? Rust?
In any case, IMO, if youâre following The Power of 10 you get used to false positives being thrown and compilers/static analyzers complaining about stuff that you know is fine, thatâs their job after all 
Commenting out code is a terrible habit! use
if (XXX)whereconst XXX = false;. AnywayâŚ
Iâm with the @sbrow on this one - this is the first time I hear that commenting code is âa terrible habbitâ. Commenting code is a pretty valuable tool in prototyping and explorative programming. I fail to see an upside in the workaround youâve provided, as it achieves the same effect of commenting code out with little to no code editor support and worse clarity.
The end game here seems to be that tabs arenât legal in Zig code, but
zig fmtwill fix them when used as whitespace. Iâm fairly sure the comment about rendering is just saying that letting the user replace comment tabs is better than auto-formatting, because the formatter doesnât know the tabstops, so it shouldnât guess.
Thatâs just seems impossible, no? If zig fmt canât autoformat comments because it doesnât know the tab width, how is it supposed to autoformat indentation? Is it just going to guess the length of 4?
it achieves the same effect of commenting code out with little to no code editor support and worse clarity.
I donât agree that it has worse clarity.
Commenting out code is implicitly invoking conditional compilation. if( [comptime expression evaluating to false] { ... } is explicitly invoking it. Doing it that way means you can integrate it with the build system, for example with a flag that removes the expression entirely (so âcommented outâ code becomes a compilation error).
Worse editor support insofar as the thing you use to temporarily comment out code becomes a snippet instead of a comment is mostly a nonissue for any modern editor, and is entirely fixable with simple language tooling.
C tools can highlight unevaluated non-comment code (removed with #ifdef instead of comments), I donât see why it wouldnât exist for Zig at some point.
Does one option over the other not depend on why youâre commenting out the code? For example, if itâs some target specific code, or something thats meant to be configurable, then sure throw it behind a flag.
But if youâre just debugging some fresh logic, and the code is destined to either be summarily deleted or brought back, I fail to see a (large) benefit in wrapping it in an always failing if.
Weird. Iâve never had a job which allows commented out code to be committed, and I always flag it when I see it in review.
The problem with commenting out code is when you find dead code in comments. Why is it commented? Was that a mistake, is it being saved for later as though revision control doesnât exist? If itâs un-commented, will that fix whatever problem brought me to that section of the code, or partly fix it, or make it worse?
Thereâs just no way to know. If youâre going to delete code, delete it. If you temporarily need it to not apply, while debugging, there are better ways to do that.
Avoiding a bad practice in favor of something better is not a âworkaroundâ. Itâs choosing not to be lazy, out of a sense of responsibility to others who may need to deal with your laziness later, and a sense of pride in oneâs workmanship.
I beg to differ. It is a preferable alternative, enabled by Zigâs lazy compilation model. if (false) conveys intention, which randomly commenting out blocks does not do. If you use if (XXX) you can benefit from a commit hook which prohibits XXX ing in code, and you can also find all the knocked-out blocks in the process of deleting the variable.
How do you grep for commented out code btw? Or is it just ok for other people to spend effort in code review double-checking that you removed all of it.
I donât agree. When Iâm having to isolate a bug and I have to activate different lines to run down a bug, this kind of if (false) {} line noise is super distracting and breaks my ability to hold the abstractions I require to create ground truth for debugging inside my head. It also makes all the diff tools Iâve ever used go nuts. If I have to re-enable a couple of disconnected lines in the middle of that mess, now I have to have multiple if (false) {} things with their attendant added scopes which change the compiler runtime behavior and may even outnumber the lines Iâm actually debuggingâagain overwhelming the signal with noise.
This is super bad when the bug you are running down has to do with concurrency and locks and Zig is causing variables to need to be defined and undefined and defined and undefined and completely scrambling the stack from run to run depending upon the commented code.
Hmmm. This is the first time anybody has articulated a benefit to that style that I can at least see the point of.
And Iâm in agreement that source control systems existâcommented code should get deleted before being pushed to production.
It just ⌠never comes up? Honestly, that is such low hanging fruit that maybe I remember flagging that for a junior dev maybe once or twice over a couple decades? Itâs certainly not something that occurred often enough that I would think about making a commit hook for it.
Yeah, I also donât see why commenting out code became a problem all of a sudden. Itâs something people do while debugging. Once youâre done debugging and ready for a commit, you review the diffs and undo any commented out lines. No big deal.
Editors even have very good support for toggling line comments, like ctrl-'/ctrl-/ in VSCode. Very handy and commenting out makes it much clearer while debugging what are the sections that are disabled for debugging purposes.
I guess not everyone works this way, and for those who donât, it may be hard to understand what the âcommenting out codeâ people are on about.
Weird. Iâve never had a job which allows commented out code to be committed, and I always flag it when I see it in review.
Iâm not talking about committing commented out code, Iâve specifically mentioned the use case of debugging, prototyping and exploring solutions. You donât commit your testing/prototyping code in general, period.
Avoiding a bad practice in favor of something better is not a âworkaroundâ. Itâs choosing not to be lazy, out of a sense of responsibility to others who may need to deal with your laziness later, and a sense of pride in oneâs workmans hip.
I will go on a side tangent here and rant a bit, but I have absolutely no idea why Zig enforces the style of programming where each little change you make to the code, not matter how inconsequential, must be treated like itâs about to be committed to the NASA codebase running on Voyager II beyond the solar system. Nobody here argues that the rules Zig enforces to the code are bad in the committed, public code. But they absolutely do tank the productivity in this language. People donât want to be lazy, they simply want their tooling to respect their time, and when every time you construct a function, introduce a temporary variable, and now - temporarily disable a block of code - you have to nanny the compiler for things that will likely not even exist in the final result, will have no influence on the resulting quality of the code. The frustration people often describe comes from a waste of time, not being âlazyâ or whatever you want to call it. There are so many possible solutions to control the quality of the code without introducing this silliness in the compiler - ranging from git hooks to only enforcing all of this when compiling in release modes, I just donât get why the developers ignore these?
Conditional compilation as a solution to this problem is the new icing on this cake. Introducing a new comptime variable and a scope, and even a compilation flag (as @tsdtas mentioned), just to emulate Ctrl-/ is absurd. Youâre telling me that some lines are starting with // may confuse the maintainer, but a piece of dead code that looks identical to the alive one wonât?
Raw commented out code that somehow got itself into the commit conveys a mistake on the programmers behalf of forgetting to remove it after experimenting. I donât understand why would anyone interpret it any other way, and Iâve never seen anyone interpret it in any other way. It itâs in a comment - it has absolutely no hypothetical way to influence the program behavior in itâs state. A const, at the very least for me, conveys some degree of configurability, which is not the thing I want for the dead code that I, or my coworker forgot to remove. Is it a const set to false because it is configureable at compile time, or is it just a mark of the dead code? If there is a build flag related to it, does it mean that this is a toggleable feature, or something an author had to write because of apparent âbestâ practices?
How do you grep for commented out code btw?
The same way you grep a random const youâve introduced as a workaround - you canât.
Or is it just ok for other people to spend effort in code review double-checking that you removed all of it.
Reviewing the code involves the reviewer reading the damn code. Youâre describing an issue that doesnât exist in the first place (and if it does - your workplace has way bigger problems than random comments amidst the code).
I like the Voyager part hahaha
Quite the impassioned thread based on one throwaway comment!
Iâm not looking over your shoulder when you code, and I wonât lie and say I never comment code out while Iâm working. You do you.
What I said is that itâs a bad habit (habit means something different from âpracticeâ), and that conditional knockouts are better, and I stand by that.
This might be some of it, I suppose. I use Neovim (btw) so commenting out a block is, like, V10jgc. But an if (false) with braces is pretty easy too: V10ksa{Iif (false) jk or something like that. Adding a const XXX = false; is something like mw'hoconst XXX = false;jk'w and Iâm back where I started. This assumes that Iâve marked the header, which usually I have.
Not trying to make an argument for Vim supremacy (or⌠am I?) but it hadnât occurred to me that one of these could be considered meaningfully more difficult than the other, or break focus more, because for me theyâre not. Conceptually, these are the same thing: I decide the result I want, I type things, it happens. Typing the phrase âman bites dogâ takes less time than ânow is the winter of our discontentâ, but not in a way thatâs meaningful to how a touch typist sees the world.
And sure, itâs true that some of the advantage of this approach is due to Zigâs insistence on code liveness, so I think some of you are taking the opportunity to get mad about that again. Well it wonât change, so the fact that this strengthens the argument for conditional knockouts over commenting out blocks wonât change either.
Do what you want. If that includes a passionate defense of your habits against something you havenât tried, so be it. If youâve tried both and strongly prefer commenting out blocks of code, for some reason or other, itâs probably not the only thing we disagree about. This is fine.
In an environment where code review and git are popular, I think the arguments against commenting out code are weak.
Code reviewers see a git diff. So commenting out code may produce a larger line-diff than conditional compilation.
Conditional compilation is more greppable, but code reviewers are not grepping my code in my experience.
Often I open a draft PR just so I can have the diff open while while I am working, so I can maintain awareness of the total amount of changes I am making.
Commit hooks use grep all the time.