Don’t Repeat Yourself (Unless Reading Book)
After reading Pragmatic Programmer at my recent vacation, I immediately found an urge to repeat myself and read it again.
Ironic that one of the most popular tips from it is “Don’t repeat yourself”. Even though the book was published in 1999 (before the agile manifesto), there are so many golden nuggets in the book, that I find myself constantly using it at work.
Many of the principles are well-known today — the DRY principle is constantly used when developing Ruby/Rails applications and is a good pointer to the ability to change code.
Many of the pragmatic tips are ubuquitous in Ruby on Rails and well known because of the popularity of agile principles. Still the book is good, relevant and everyday useful. And most of the tips from the book can be applied for motivation in the projects I work on.
Bonus link: Jeff Atwoods article about the Department of Redundancy Department:
I have an awfully hard time defending the unnecessarily verbose way objects were typically declared in C# and Java.
BufferedReader br = new BufferedReader (new FileReader(name));Who came up with this stuff?
Is there really any doubt what type of the variable br is? Does it help anyone, ever, to require another
BufferedReader
on the front of that line? This has bothered me for years, but it was an itch I just couldn’t scratch. Until now.
Technorati Tags: book, review, dry, repeat, repetition, pragmatic programmer, pragprog, code
June 25th, 2008 at 22:01 (GMT-1)
Yeah you said it right don`t repeat yourself or in other words Golden words should not be repeated.
July 18th, 2008 at 10:38 (GMT-1)
IMyInterface x = new ImplementationClass();
Thats why it is repeated!!!!
But you could have a point that the languge should have a way to just say
IMyClass = new ()
if its just an instance of the same cla
August 19th, 2008 at 11:52 (GMT-1)
C# actually introduced the “var” keyword in 3.0
var br = new BufferedReader(…);
implies that br is a BufferedReader
To elaborate on Kajs reply:
when using inheritance, any superclass (including interface definitions) are valid members of the type of the subclass. Therefore it is necessary to be able to define the type of the object. This needs not be the case with ducktyped languages, which I suspect that ruby is (without bothering to read the spec)
March 12th, 2009 at 07:25 (GMT-1)
I love to read a book or even an article that has plenty of “handles” that I can take away. On your recommendation, i think I will have to run out and get this. There are some of these kinds of things that I have taken with me for my entire life.
November 6th, 2009 at 16:30 (GMT-1)
I wish I’d known about the don’t repeat yourself guideline before I started writing the ruby application I’m working on now. It really does pay to take a little more time to do something just once. Going back over code and changing things on 50 scripts can be a nightmare.