3 ms·
Urgh this frustrates me so much. The worst part is, the recommended way to avoid these compilation problems is to add: _ = my_unused_variable; to your co
by josephg 1y ago
Urgh this frustrates me so much.
The worst part is, the recommended way to avoid these compilation problems is to add:
_ = my_unused_variable;
to your code. Some IDE extensions even do this automatically. But if you do that, it permanently suppresses all compiler feedback that my variable is unused! Its basically the worst of all worlds:
- I can't easily prototype, or test code as I go because I keep stubbing my toe on irrelevant unused variables. And these are compilation errors, not warnings.
- In order to test my code, I need to go and fix all the unused variable errors (either automatically or manually). But once I've done that, they're essentially suppressed forever. Now I don't even get warnings, and I'm at risk of shipping code with unused variables. Now I need to manually scan my code, looking for times when _ = x was only added as a placeholder. Will I forget some? You bet.
So I end up in a situation where its both less convenient than other languages (I have to do more work to test my code). AND I'm more likely to ship bad code - since by the time I'm done, half my unused variable warnings have been manually suppressed and I can't find out where they are.
This obviously works for some people. Maybe some people never try running their code as they go. But its just horrible for me. It breaks my workflow and risks me shipping worse code. And it provides no actual benefit in return.
- 90s_dev 1y ago> (I have to do more work to test my code) I feel like that's already the cultural precedence in Zig. I mean, isn't their primary way of making sure your code fully and oncely frees all memory, just writing tons of tests that thoroughly exercise your function(s)?
- josephg 1y agoSure; but when I'm working on a complex problem, I'll often run (test) my code as I go, eyeballing the input and output to make sure I'm on the right track and its doing what I expect. The less time that passes between writing code and discovering a bug, the easier it is to find and fix the bug. Its also a great way to write tests - I'm more aware of edge cases when I've just written the code being tested. The problem is that zig makes it hard to run the first half of a function or block of code. I've always got variables or parameters that I simply haven't put to use yet. In an ideal world, my half-written code would fit neatly into a set of well defined functions with no unused variables. But at an experimental stage, I haven't refactored my code to make it beautiful yet. I always prefer to debug my code before refactoring it, because if my tests fail afterwards, I can isolate the bug to the refactoring process itself.
- 90s_dev 1y agoI don't disagree with anything you said, I was adding to it, and showing evidence that it seems to be a problem with Zig community's culture. > at an experimental stage, I haven't refactored my code to make it beautiful yet. I always prefer to debug my code before refactoring it, because if my tests fail afterwards, I can isolate the bug to the refactoring process itself. Yes, that is inherently the best way to write code. The right flow is, 1) make it work 2) make it work right 3) make it work for the right reasons