3 ms·

There are no absolute truths in coding, so don't pretend there are. These are classic rules of thumb that are good to read every once in a while. Take from them

There are no absolute truths in coding, so don't pretend there are. These are classic rules of thumb that are good to read every once in a while. Take from them what you like, leave the rest alone.

limmeau 14y ago
I prefer to think about these rules in terms of bets. Adding e.g. a symbolic constant is a bet. You win if during the lifetime of the system, you discover that the constant must be changed, and the gain is the time saved by changing it quickly and with few errors. If you never have to change the constant, you lose the time spent on introducing the constant and the time spent on looking up the constant while reading the code. Most of the rules here are long change (or whatever the financial people call betting on something), except for KISS.
- tinco 14y ago
  I agree. Also, extracting to methods and constants is long on on the idea that the code might be harder to understand without meaningful symbols in the future, which is a pretty safe bet usually :)
tinco 14y ago
So that there are no absolute truths in coding.. is an absolute truth in coding? Please don't pretend to be able to tell me what to pretend, I don't think it's conductive to the discussion. I don't think these are rules of thumb that you should take for granted without criticism, especially when paraphrased from their original (well researched) source. And I especially don't think you should take from them what you like. They are principles you should know because they are known to lead to well designed software, you should leave none of them alone.
justin66 14y ago
> Take from them what you like, leave the rest alone. The person you responded to mentioned novice programmers. Teaching novice programmers with the attitude of "use as much of this as you like/want/understand" is a pretty poor technique that will not give good results.

There are no absolute truths in coding, so don't pretend there are. These are classic rules of thumb that are good to read every once in a while. Take from them what you like, leave the rest alone.

limmeau 14y ago

I prefer to think about these rules in terms of bets. Adding e.g. a symbolic constant is a bet. You win if during the lifetime of the system, you discover that the constant must be changed, and the gain is the time saved by changing it quickly and with few errors. If you never have to change the constant, you lose the time spent on introducing the constant and the time spent on looking up the constant while reading the code. Most of the rules here are long change (or whatever the financial people call betting on something), except for KISS.

tinco 14y ago
I agree. Also, extracting to methods and constants is long on on the idea that the code might be harder to understand without meaningful symbols in the future, which is a pretty safe bet usually :)

tinco 14y ago

So that there are no absolute truths in coding.. is an absolute truth in coding? Please don't pretend to be able to tell me what to pretend, I don't think it's conductive to the discussion. I don't think these are rules of thumb that you should take for granted without criticism, especially when paraphrased from their original (well researched) source. And I especially don't think you should take from them what you like. They are principles you should know because they are known to lead to well designed software, you should leave none of them alone.

justin66 14y ago

> Take from them what you like, leave the rest alone. The person you responded to mentioned novice programmers. Teaching novice programmers with the attitude of "use as much of this as you like/want/understand" is a pretty poor technique that will not give good results.