The Rule of Three
codinghorror.com
The Rule of Three
1–10 of 31 posts
Re: The Rule of Three
#2Nice post. I was more interested in the fact that Discourse was being real-world tested/developed with three clients than this trite "rule of three" business though.
Re: The Rule of Three
#3[deleted]
Re: The Rule of Three
#4At first I thought this might have been a repost of some refactoring advice I heard of long ago. A quick google finds a reference on wikipedia [0]. Essentially it goes like this:
The first time you implement something, just do it.
The second time you implement the same thing, copy it.
The third time, refactor.
[0] http://en.wikipedia.org/wiki/Rule_of_three_(computer_program...
Re: The Rule of Three
#5I remember that a Xorg development guideline explicitly required the same code to be used by at least two different subsystems (using hard coded if-based paths or copy/pasted) before it could be generalized into a parametric reusable function.
Re: The Rule of Three
#6 Less than three? Control-C, Control-V.
Three or more? Refactor!Re: The Rule of Three
#7At first I thought this might have been a repost of some refactoring advice I heard of long ago. A quick google finds a reference on wikipedia [0]. Essentially it goes like this: The first time you implement something, just do it. The second time you implement the same thing, copy it. The third time, refactor. The OP seems like an interesting variation on the same theme. [0] http://en.wikipedia.org/wiki/Rule_of_three…
This is similar to Jeff's rule "b". The only difference is cause and effect ordering. Jeff suggests you build it, reuse it, and when you reused it thrice in different applications, than call it a general purpose library.
It seems to me that Jeff misunderstood what rule of three means, or he's just trying to re-tell the Wikipedia article in his own words.
The "Rule of three" you quoted is how it should be done. Create, copy/paste, refactor to be reusable. And there's nothing wrong with that.
Re: The Rule of Three
#8At first I thought this might have been a repost of some refactoring advice I heard of long ago. A quick google finds a reference on wikipedia [0]. Essentially it goes like this: The first time you implement something, just do it. The second time you implement the same thing, copy it. The third time, refactor. The OP seems like an interesting variation on the same theme. [0] http://en.wikipedia.org/wiki/Rule_of_three…
This is similar to Jeff's rule "b". The only difference is cause and effect ordering. Jeff suggests you build it, reuse it, and when you reused it thrice in different applications, than call it a general purpose library. It seems to me that Jeff misunderstood what rule of three means, or he's just trying to re-tell the Wikipedia article in his own words. The "Rule of three" you quoted is how it should be done. Create…
To be fair to Jeff, he was quoting from "Facts and Fallacies of Software Engineering" by Robert Glass [0].
The two rules are very similar, and that's why I think they have the same 'theme'. In one we are talking about when to refactor and in the other when to create a library, but both are essentially the same idea. Don't spend time generalising something that might never be used again. Three existing uses is (apparently) a good heuristic for answering "When is something going to be reused lots?"
Re: The Rule of Three
#9Wow what a horrible way to advertise your products. Disguise your advertisements into some substanceless article seemingly useful.
Re: The Rule of Three
#10I like the sentiment. Battle testing your generalised solution is always a good idea. It's also a good idea to know when you don't need a generalised solution.