Code should describe itself. This is a statement everyone agrees on.
Whether or not comments should add to this description is somewhat of an everlasting debate.
I’d like to present you with a question:
One rule in a system declares that “an integer that’s value is not greater than 8 is a valid X” (sic).
Another rule in that system declares that a certain variable should “not be a valid X” (sic).
It was decided that there should not be a method returning a boolean value whether or not an integer was a valid X or not and 8 should not be a constant.
How would you decide to write this?
The obvious answers would be:
1. (!(!(myVariable > 8))).
2. (!(myVariable <= 8)).
3. myVariable > 8.
I would rather write the code using option 1. In my opinion, it best describes the situation, since the documentation declares that “myVariable should not be X” and if expanded, we get a double negation which reads “myVariable should not be a value that is not greater than 8”.
If your first thought was “You’re saying that you’d rather do two more operations (not and not) in order to do something I could do with one operation with option 3”, then I can tell you that it all comes down to the exact same IL, thanks to the compiler.
What do you think?
[Update: Some very interesting conversation in the feedback. Be sure to look into it.]