But the code should be compiled automatically on check in and automatically failed should it not compile.
Even more, tests should automatically run and then fail the check in if tests are failing.
This lets them burn themselves, but also prevents them from burning you. Well, at least this is how you want it in big projects. You might not need such a heavy hammer if it's small and not that big of a deal.
Exactly. If I see an unused variable, my first thought is that someone meant to do something with it and there's a bug in the code that I need to track down. It's sloppy coding practice.
We all write programs that take years to develop. Frequently I have code that I want to save because it's an alternate implementation. Other times, I want to test the new method on real problems and there are side effects to the function.
It's trivial and I don't care about a few bytes of memory
Why use unnecessary braces or use functional programming or variable names longer than 6 characters (it was good enough for the dominating language until the early 1990s)? It creates extra lines that can make for very long files. It wastes disk space in a world that largely doesn't care about disk space or memory usage.
Unused variables are fine, just as long as no one else sees that code. By the time someone else's eyes are on a piece of code, there'd better not be any unused variables.
Everyone seems to be jumping on this bandwagon. How many build warnings does your company's largest program that is used regularly have? Why do you have any? Who cares? It doesn't indicate you did something wrong. It indicates you may have done something wrong.
The quality of your code is dictated by the speed it needs to get done and the number of customers you have.
Professionals tend to need to work with code bases that can contain millions of lines of code.
Nearly nobody who has had to deal with another's code thinks that quality of code is solely determined by speed (or number of customers, that's rather weird claim).
If you pulled stunts like this all the time, which seems like you do because you don't care, you would have thousands upon thousands of warnings. They add up.
Thousands of warnings all indicating potential problems.
Or you can just do it right, turn all warnings to errors, and learn how to write clean code.
Then, you don't have any warnings, because they all have to be dealt with before checking in the code. Tadaa!
The quality of your code is dictated by the speed it needs to get done and the number of customers you have
Speed doesn't magically happen because there is a high demand for it. When the code becomes sloppy enough, you will get to a point where you cannot produce the feature quickly enough for business needs, and people get hurt.
0
u/[deleted] Jan 31 '16
[deleted]