4 ms·
It's not bad advice, if used in moderation. The problem is that most developers take it too far, to the point where no number is safe from becoming a named cons
by s_tec 11y ago
It's not bad advice, if used in moderation. The problem is that most developers take it too far, to the point where no number is safe from becoming a named constant.
My default these days is to write numbers as numbers, plus maybe a comment if things are unclear. I only turn numbers and strings into named constants if they are used in more than one place, or if they are true configuration values that need to be tweaked.
This makes the program easier to read (the ultimate goal) by avoiding the need to jump around in the codebase. Comments are better at explaining things than cryptic variable names anyhow.
- sken 11y agoDefinitely, although there can also be refactoring benefits to look out for. In the article example it would be much easier to change the default popup window size (800x800) across the project if they're all using the same variable. On the other hand, tools like CheckStyle can make people do some strange things when they take it too literally. I once reviewed code that defined: static final int ONE_HUNDRED = 100;
- s_tec 11y agoRight, but your window size example would be a case of using the same value in more than one place, so it would be better as a named constant. Actually, the whole example smells ripe for refactoring. Where are there multiple windows throughout the app all sharing a default starting size? Sounds like it's time for a base class or something. Once you've eliminated the redundant sizing code, you will find that your default size values now exist in only one place (the base class). Since they are only in one place, you can write them as numbers again instead of named constants. I've played this pattern out more times than I can count. The problem isn't magic values sprinkled through the code; it's having redundant code in the first place. Once you solve that, the magic numbers tend to evaporate.
- leni536 11y agoMaybe 100 is a not-so-famous mathematical constant named after John One Hundred. Who knows?
- kibibu 11y agoCould have been worse: static final int ONE_HUNDRED = 200; // Changed to 50 to optimize
- danieltillett 11y agoLol - I have to say that I have seen this sort of thing a few times in the past. I actually don't mind this as it is a flashing red light that the code that uses this constant needs to be looked at very, very carefully and rewritten.
- a3n 11y agoI'm still laughing. And it's funny because it's true. And ... the funny could have been eliminated if the named constant had just had a useful name, or been replaced by a function, rather than a passive-aggressive response to a code analyzer or coding standards ("There, I fixed it."). The conflict between the name and its value would have been eliminated, and the comment may have never been written in the first place.
- zelos 11y ago> I once reviewed code that defined: static final int ONE_HUNDRED = 100; I saw: static final int ONE_HUNERD = 100; a while back, which really made me laugh.
- arethuza 11y agoI've mentioned this on HN before, but I remember seeing some code years ago that had: static final String HTTP = "http"; static final String COLON = ":"; static final String SLASH = "/"; String url = HTTP + COLON + SLASH + SLASH + ....; Which I guess isn't wrong, but isn't right either :-)
- mercurial 11y ago> Comments are better at explaining things than cryptic variable names anyhow. I'd pick const DEFAULT_FONT_SIZE = 42; // ... lots of code in the same file var font = new Font(DEFAULT_FONT_SIZE) over // 42 is the default font size var font = new Font(42); any time. Two reasons: version 2 encourages others to copy-paste out of laziness, and it does not resist refactoring very well.
- deleted 11y ago[deleted]