Hacker News Reader

Comment by Aardwolf | Hacker News Reader

IMHO the time for doing analysis like this is before submitting code, not before compiling it.

Ideally you want code without unused variables, implicit type casts, ... in a repository. But when you are locally testing out code you're in progress of writing, it is very unproductive if you have to care about unused variables because you're commenting out one line to see the difference, or change casts everywhere because you change the type something temporarily. It'd be nice to only do the work of cleaning up such issues in the final version of your change.

These checks are enabled by default in many environments, build tools or scripts for them etc..., it's not trivial to disable it or requires full recompile.

So I wish a language or build environment would use the concept of "development time" vs "submitting time" for different sets of warnings-as-errors.

View on HN

This is one recent change in Zig which really annoys me: unused variables are now errors. Languages that complain every time there's a unused variable become useless during experimentation and quick hacking. They turn my hyperfocus into a death from a thousand paper cuts.

I hate it with a passion. Please respect my mental flow, if I'm trying some ideas out, it's just rude to stop me in my tracks to tell me I forgot to comment out a variable. Who cares.

I will fight anyone who thinks this is a good idea.

I have to agree with you. Zig already has a Debug build mode, they can just warn if you are running Debug build.

For a variety of reasons, Zig doesn't do warnings.

Personally I don't get the big deal with unused variables being errors, from either direction. I'm not sure what it accomplishes to make them errors and I'm not sure why people complain so much about having to comment them out.

If you comment out a statement, you cannot know for sure how many unused variables this caused unless you visually scan the entire previous code, which can cost time.

So the only way to find out is to compile and then have the compiler tell you that it refuses to continue because there's an unused variable at line X.

So now you needed to do not one but 2 compiles, to do something that should have taken 1 compile, which also costs time.

But it's then also possible that due to commenting out line X, there's now yet another unused variable (or more) somewhere. Etc... (Unless the language offers a way to fake-use the variable, like (void) cast in C++. Then at least you only have one wasted compile and not recursively more)

And then if you want to enable the original line that you commented out again, you need to also remember to uncomment out those other lines.

Repeat this process many times a day when really in progress of developing something, and due to the total time it costs for this silliness it's just a bad tool, not a good tool for efficient programming in the flow.

The goal of the unused variable as error is to prevent bad submitted code, but that should not cost you time during development. Only enforce that check at the end, not during.

> Unless the language offers a way to fake-use the variable

Zig actually does have this:

  _ = my_variable;

I think that one thing that we really need to revisit in PLs is sorting out different kinds of comments. Like, in most languages, a comment is just whitespace, with no semantic distinctions. More recently, docstrings got some special handling. But what's really needed is a kind of comment that's specifically about commenting out code; ideally, working on syntax tree level (so you can comment out one entire {...} block, say), and with the compiler being aware that the stuff inside is code, and handling it accordingly for purposes such as these.

Yeah, basically what the other commenter wrote - it requires potentially many changes recursively.

Earlier in Rust, I saw people recommending `#![deny(warnings)]` (always turn warnings into errors) but I think the community has shifted since then because I feel like I don't see that as much and instead see people disabling warnings in CI.

Speaking of warnings, something I appreciate about Rust is you only see warnings for your own code and not for your dependencies so you can crank up the warnings to whatever level you want without being blocked by dependencies (minus macros). Granted, there could be times where looking at high risk warnings for dependencies could be important.

I'm using cargo-limit crate for "cargo lcheck", "cargo ltest" or "cargo lclippy" to show errors before warnings before clippy warnings. You're right that "cargo check" gives the same priority to warnings as errors, and it's annoying.

Reply on news.ycombinator.com