Many good programming practices boil down to preparing for change or expressing intent. It seems to me that novices emphasize the former, experts the latter.
One of the first things you learn in programming is to use symbolic constants rather than magic numbers. For example, if you have a maximum of 12 items in a shopping cart, define a constant like MAX_ITEMS to be 12 and use that symbol rather than the number “12” throughout the code. That way if you have to increase the maximum to 25 some day, you can just make the change in one place. Symbolic constants prepare for change.
Sounds good, but then why define a constant for pi? It’s not going to change. But having a constant PI in source code conveys the intention of the number.
There are 3,628,800 seconds in six weeks. Coincidentally, this number also equals 10!. But constants like SECONDS_PER_SIX_WEEKS and TEN_FACTORIAL clearly convey where the numbers come from. That’s why it’s sometimes worthwhile to give one thing two names. The symbol SECONDS_PER_SIX_WEEKS looks like a conversion factor, while TEN_FACTORIAL makes you think somewhere there are 10 things being arranged. Using the symbols in the opposite context would be clever, but not in a good way.
Expressing intent is easier to justify than preparing for change. If you argue that some chunk of code should be pulled out into its own function in case it needs to change, someone may argue “But that’ll never change.” If you argue that the same chuck of code should be pulled out and given a name to express what it’s trying to do, you’re likely to get less resistance.
If you focus on making your intentions clear, your code will be easier to maintain. If you focus on maintainability alone, it might backfire. You might get lots of unneeded code, inserted with the intent of making future maintenance easier, that makes maintenance harder.
More software development posts
A maintainable code allows more easily to take care of unexpected cases, like when 6 weeks last one second more because of a leap second.
Great article, while I always did both (prepared for change & expressed intent) I never articulated those ideas like this.
You are quoted at page 41 of the book “Advanced Metaprogramming in Classic C++”, by Davide Di Gennaro. Apress, 2015. http://www.apress.com/us/book/9781484210116
https://books.google.it/books?id=m2cnCgAAQBAJ&q=novices+emphasize+the+former%2C+experts+the+latter#v=snippet&q=novices%20emphasize%20the%20former%2C%20experts%20the%20latter&f=false
And do not use
SECONDS_PER_SIX_WEEKS = 3628800
but use
SECONDS_PER_SIX_WEEKS = 6 * 7 * 24 * 60 * 60
When someone needs to change it to seconds per seven weeks, it will be much easier for him and the number looks a lot less like a “magic number”.
And most programming languages will evaluate the expression at compile time anyway.