4 ms·

Caring about magic numbers is a distraction from real problems, such as getting your software working.

jneal 13y ago
Maybe...But caring about magic numbers can also keep your software working properly.
timje1 13y ago
Once the software's working, and has been for several years, and it has become unmaintainable because lax guidelines let this stuff through, this sort of thing becomes your real problem.
- xyzzy123 13y ago
  Nah, ubiquitous session re-use, bad APIs, arbitrary data structures (e.g everything in complex sets of nested arrays), hardening of code against static analysis (e.g. database lookups to instantiate classes at runtime) rate way higher on my scale. Local use of magic numbers (across 1 file) don't bother me any more, although I will recommend fixing them when I find them.
SanjayUttam 13y ago
Because doing so is one of the many measures you can take to ensure your software is (and stays) easily maintainable. Getting your SW working is only really one stage of a product life cycle.
bitwize 13y ago
I once worked with a guy who thought like this. His work was a morass of hundreds-of-lines-long VB methods. And when it stopped working, it stopped working hard, and I had to pick up the pieces. Good programming practices are not a distraction from getting it working. They're essential to keeping it working, even in the face of changing requirements and unanticipated circumstances.
- a3voices 13y ago
  I agree, but they should be guidelines, not rules. Messy code is one extreme, and having perfect-looking code is the other. Clearly there's a balance somewhere.
  - recursive 13y ago
    Having perfect looking code has very little drawback.
    - xyzzy123 13y ago
      It takes time to polish, and over-DRY is a kind of disease.
crpatino 13y ago
Not if you care about maintainability. I was about to go into a rant about that moron that named its variables after Starwars characters and then left for a better paying gig, leaving his unmaintainable mess for others to care about, but it would be unfair for me to project my own traumas into you. Besides... it was 2007, so I better learn to let go. Instead, I am going to say that getting your software working is one important goal, perhaps the most important goal because by doing that you get the money and the social capital that let you keep going and accomplish the other goals, but it is not the only goal. Other goals, such as maintainability, are important too, and they come with their own sets of requirements and constrains, often conflicting with those of other goals. If you want to call yourself a professional, you must recognize those conflicts and make deliberate tradeoffs based on local conditions, and never gratuitously undermine any set of goals just for the sake of it. Or you can make a whole career out of bluffing and waving the "get shit done" mantra. Never keeping the same job long enough for the consequences of your own poor decisions to come back and bite you in the ass.
sophacles 13y ago
It isn't hard (actually it's pretty easy) to get in the habit of replacing magic numbers with named constants immediately. Any time you hardcode a number just name it instead, and on the line immediately above it define the constant with a "TODO: refactor to the right place" comment. That way when you're done with the current creative focus, you can go back and put it right. This fixing is great for boring meetings, warmup/rezoning time, and so on. Alternately just keep a bookmark to the #defines in your editor and go drop it in the right place immediately. Doing this makes life convenient because magic numbers often turn out to be real problems - did you typo the number somewhere? Did you forget to update the magic in one spot? These bugs waste more time in hunts than they cost in "do it right immediately".
benjaminwootton 13y ago
Refactoring out magic numbers (and magic strings!) is one of the easiest refactorings you can do. Not putting in the effort to pull these out shows a complete disregard for code quality and maintenance.

jneal 13y ago

Maybe...But caring about magic numbers can also keep your software working properly.

Once the software's working, and has been for several years, and it has become unmaintainable because lax guidelines let this stuff through, this sort of thing becomes your real problem.

xyzzy123 13y ago
Nah, ubiquitous session re-use, bad APIs, arbitrary data structures (e.g everything in complex sets of nested arrays), hardening of code against static analysis (e.g. database lookups to instantiate classes at runtime) rate way higher on my scale. Local use of magic numbers (across 1 file) don't bother me any more, although I will recommend fixing them when I find them.

SanjayUttam 13y ago

Because doing so is one of the many measures you can take to ensure your software is (and stays) easily maintainable. Getting your SW working is only really one stage of a product life cycle.

bitwize 13y ago

I once worked with a guy who thought like this. His work was a morass of hundreds-of-lines-long VB methods. And when it stopped working, it stopped working hard, and I had to pick up the pieces. Good programming practices are not a distraction from getting it working. They're essential to keeping it working, even in the face of changing requirements and unanticipated circumstances.

a3voices 13y ago
I agree, but they should be guidelines, not rules. Messy code is one extreme, and having perfect-looking code is the other. Clearly there's a balance somewhere.
- recursive 13y ago
  Having perfect looking code has very little drawback.
  - xyzzy123 13y ago
    It takes time to polish, and over-DRY is a kind of disease.

crpatino 13y ago

Not if you care about maintainability. I was about to go into a rant about that moron that named its variables after Starwars characters and then left for a better paying gig, leaving his unmaintainable mess for others to care about, but it would be unfair for me to project my own traumas into you. Besides... it was 2007, so I better learn to let go. Instead, I am going to say that getting your software working is one important goal, perhaps the most important goal because by doing that you get the money and the social capital that let you keep going and accomplish the other goals, but it is not the only goal. Other goals, such as maintainability, are important too, and they come with their own sets of requirements and constrains, often conflicting with those of other goals. If you want to call yourself a professional, you must recognize those conflicts and make deliberate tradeoffs based on local conditions, and never gratuitously undermine any set of goals just for the sake of it. Or you can make a whole career out of bluffing and waving the "get shit done" mantra. Never keeping the same job long enough for the consequences of your own poor decisions to come back and bite you in the ass.

sophacles 13y ago

It isn't hard (actually it's pretty easy) to get in the habit of replacing magic numbers with named constants immediately. Any time you hardcode a number just name it instead, and on the line immediately above it define the constant with a "TODO: refactor to the right place" comment. That way when you're done with the current creative focus, you can go back and put it right. This fixing is great for boring meetings, warmup/rezoning time, and so on. Alternately just keep a bookmark to the #defines in your editor and go drop it in the right place immediately. Doing this makes life convenient because magic numbers often turn out to be real problems - did you typo the number somewhere? Did you forget to update the magic in one spot? These bugs waste more time in hunts than they cost in "do it right immediately".

benjaminwootton 13y ago

Refactoring out magic numbers (and magic strings!) is one of the easiest refactorings you can do. Not putting in the effort to pull these out shows a complete disregard for code quality and maintenance.