Comment by tinco | Hacker News Reader

Comment by tinco | Hacker News Reader

The author lacks conviction:

    "if you use a hardcoded value more than one time consider making it public final constant"

This should obviously be: "if you use a hardcoded value, make it a public final constant"

And:

    "if you have block of code in more than two place consider making it a separate method."

This should be: "if you have a block of code, consider making it a separate method"

Also, half of these principles imply the other ones.

edit: This is meant seriously btw, if you're giving advice to novice programmers, the instructions should be clear. If you say 'consider making a separate method' what should the programmer consider? If the programmer is new to this he or she won't know what considerations to make either.

This goes for all principles by the way, they're all fine and dandy but they're also trade offs. Every time you abstract something, you risk obfuscating the code for the uninitiated.

As arethuza suggests, Keep It Simple Stupid is also a solid design principle, and it contradicts a whole lot of the other principles.

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.

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.

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 :)

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.

> 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.

I don't agree with "if you have a block of code, consider making it a separate method". I've seen it done and done it myself in the past, and it ended up being a whole lot of methods used only once and described well (by name). However it added unnecessary complexity which added to the cost of ownership of the classes. I hope someone can relate.

I can relate - it can also be a way where you can introduce meaning to your code. As opposed to a a series of instructions without clear intention, you can put them in a function that has a name that signals your intention. So you are labelling what that code does, using language features. I'm sure there are plenty of examples of this done well and done badly.

Not only meaning, but also separation. Two chunks of code after each other in a method can communicate via all kinds of mechanisms, e.g. having the same variable in scope. As a reader you will have to check for these communications to understand the method, even if those two blocks of code do not in fact communicate.

If you separate the block out into their own methods, they reader will have a much easier time verifying that they are decoupled.

Originally it was ""if you have block of code in more than two places", tinco removed that from their reply.

I believe that inclusion solves the issue you've described. Obviously you don't need every 5 lines of code encapsulated into a method, but preventing code duplication should be paramount.

When you consider an act, you decide whether or not to perform that act. Consideration does not imply causation.

While it's not necessary to pull every block of code out into it's own function, its something a developer should keep in mind when writing code.

A lot of people seem to thing that code duplication is the only reason to refactor code out into it's own function. While that's certainly a good reason, there are many others. For me, being able to test the code easily is a major one. The smaller the function (specifically the less branching and the less it does), the easier it is to test.

Obviously, it's a balancing act.

I think the wishy-washy wording you see are the result of a non-native writer relying on cliches to overcome their lack of skill in English. It's easy for an unskilled person to sound arrogant or rude when they try to be firm and concise.

Reply on news.ycombinator.com