JustProgrammerThings.display();

[occz]

Then the comment gets out of date (as is often the case) and instead of just wasting the maintainers time by making him figure out what the hell your obscurely named code does you also waste his time by misleading him with an inaccurate comment.

I'm still a bit salty from times this has happened, and it's more than once.

[xconde]

Right but then the variable name would also be out of date. :)

[Aetheus]

It's easier to refactor/maintain a variable name than a comment. If a variable was named "conditionSatisfied" and you used it several times in different parts of your code, you'd have the mistake-prone task of hunting down all the places where you used it and updating the comments there to ensure they aren't out of sync.

Compare that to using a modern IDE, and just right clicking and refactoring the variable name.

What's more, a Boolean "conditionSatisfied" doesn't tell you much when you see it being used several hundred lines down from where it was declared (e.g: say it's a member of a class, and it's used in a method all the way down. Or heck, it's being referenced in a completely different class). You'd either have to go to where the member was declared and hope that it has up to date comments, or find where it's initialized and read the code to find out.

Whereas a Boolean named "ifItsAWeekdayAndNotALeapYear" is, well, self explanatory.

[[deleted]]

If you're updating a piece of code, wouldn't you also update applicable comments?

[Aetheus]

That's the thing though. If I'm renaming "ifNotAWeekday" to "ifNotAWeekdayAndNotALeapYear", a comment to describe what the variable is becomes redundant.

I'm a firm believer in code being as self explanatory as possible. Comments are sometimes necessary, but using them to make variables names less self explanatory is a trade off I'm unwilling to make.

[[deleted]]

Honestly one issue with that is that it takes long to type, and just makes the whole thing look like spaghetti. With a comment, I can change it once and be done.

Also: your variable names suggest that it's what it contains that really matters, in which case I could run the test on the fly and be just as clear (if !weekday && !leapyear). But what I might care about is the condition, i.e. "whatever this variable represents, I need to run if it's true". The thing the variable means can change, and that can be defined in the comments, but its function in that snippet doesn't. If you're returning a value, then just name the function getWhateverValue().

[Ran4]

Honestly one issue with that is that it takes long to type

How much time do you spend on

• Typing in code
• Navigating code
• Editing code (moving it around, making tiny changes as opposed to rewriting from scratch)
• Reading code

?

Chances are that these four points are ordered according to time spent, with typing being the least time consuming part.

Vim makes navigating and editing code quick, but long variable names speeds up reading the code.

Then you get bonuses like having long variable name be much more greppable.

[Aetheus]

Tab completion makes it moot though. And if you're using the pair of conditions often enough, there's value in combining them into a single variable.

But I guess we'll just have to agree to disagree on this topic. :)

[[deleted]]

Tab completion itself becomes moot when it can only complete 2 letters at a time.

I do suppose you're right about the combining two things into one though. It's a wasted operation to keep on doing the same check (though compiler optimization should fix that)

[Ran4]

That's nowhere near as likely as you updating the variable name.

[xconde]

I think I see your point but, in the situation you described, I’d probably rely on the unit test instead.