4 ms·

> "Magic Numbers and Strings" I don't know about this one...we need something have a chuckle (or cry) about over beer after work, and to make sure software arc

by smegel 11y ago

> "Magic Numbers and Strings" I don't know about this one...we need something have a chuckle (or cry) about over beer after work, and to make sure software archaeologists in 100 years time have an interesting job (not to mention plenty of opportunities to write blog-spam)!

mreiland 11y ago
That one stuck out to me as well, but for a different reason. I think the idea that "explicit is better than implicit" is a good idea for more than simply "magic numbers and strings". I much prefer seeing the code in front of me than having to jump through multiple functions across several source files + tracking down the configuration values I'm looking for because someone decided to use DI. I'm not saying DI is a bad practice, but unless you really need it, prefer explicit dependencies. And on and on with just about everything you do, if all things are equal, prefer explicit over implicit.
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 ago
  Definitely, 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 ago
    Right, 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 ago
    Maybe 100 is a not-so-famous mathematical constant named after John One Hundred. Who knows?
  - kibibu 11y ago
    Could have been worse: static final int ONE_HUNDRED = 200; // Changed to 50 to optimize
    - danieltillett 11y ago
      Lol - 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 ago
      I'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
- 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]

by smegel 11y ago

mreiland 11y ago

That one stuck out to me as well, but for a different reason. I think the idea that "explicit is better than implicit" is a good idea for more than simply "magic numbers and strings". I much prefer seeing the code in front of me than having to jump through multiple functions across several source files + tracking down the configuration values I'm looking for because someone decided to use DI. I'm not saying DI is a bad practice, but unless you really need it, prefer explicit dependencies. And on and on with just about everything you do, if all things are equal, prefer explicit over implicit.

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 ago
Definitely, 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 ago
  Right, 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 ago
  Maybe 100 is a not-so-famous mathematical constant named after John One Hundred. Who knows?
- kibibu 11y ago
  Could have been worse: static final int ONE_HUNDRED = 200; // Changed to 50 to optimize
  - danieltillett 11y ago
    Lol - 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 ago
    I'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
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]