My Notes on “The Pragmatic Programmer”

“The Pragmatic Programmer” by Andy Hunt and Dave Thomas is a critically acclaimed book that covers many non-theoretical software development practices. I chose to read the book based on many recommendations/references I had seen online and am greatful for the decision. It is a book that I plan to come back and read year after year to understand how I’m applying the topics and how I can better use them.

I thought about writing a “review” of the book, but after reading other reviews on the book online, I felt that I could better document what I took away from it by following what one fellow reader did by listing the tips that he is going to focus specifically on:

Tip 16: Power Editing. In this Tip, the Pragmatic Programmers state that you should know your editor like the back of your hand. This saves you time and gets some of the monotonous work done faster. Since my current IDE of choice is Microsoft Visual Studio 2008, I’ve gotten some posters from Microsoft that show the default C++ Key Bindings. I’m planning on printing these posters out and hanging them next to my monitor.

Tip 23: Assertive Programming. This Tip covers the need to never assume the obvious. In code that I maintain at work, there are a couple methods that return pointers to objects. It is currently assumed that these methods will never return a null pointer. To change this pattern, I plan on taking constructs like this and refactoring them to first assert that the pointer is not null, then convert the pointer to a reference and return the reference. This way, no calling method will have to assert that the pointer is not null.

Tip 26: Decoupling and the Law of Demeter. The Law of Demeter states that no block of code should know the internals of any object that it doesn’t own. This law can be simplified by stating that in languages like Java or C#, there should never be more than one period per statement (as always, some exceptions apply). Sometimes, refactoring to follow this law creates quite a few small wrapper methods, but these negative side effects don’t outweigh the positive gains that come from following this law.

Tip 43: Ruthless Testing. I have set a standard for myself in that I will not write code that is not tested. I have been working on integrating MSTest with Google Mock at work in to our MFC project, and this process will hopefully lead to less regression and improve the reliability of the product. In some circumstances, like GUI programming, I plan on maybe using another testing suite like Selenium (for websites) to test out the layout of the application. This will save me time and also help make the product better. I now will be able to run the tests to see if what I am creating is working as expected instead of starting up the program and trying to follow a specific work flow to regenerate a bug or validate that the specific bug is no longer around.

As I said earlier, I truly enjoyed reading The Pragmatic Programmer, and I highly recommend you to read it if you haven’t. I’ll be coming back to the book in the future to evaluate my progress and look at other Tips I can focus on.

Finished reading Pragmatic Programmers

I’ve just finished reading The Pragmatic Programmer book, and I should have some notes on it up here shortly. In the meantime, I hope to finish reading Effective STL.

If you have any books that you would recommend, leave a comment on this post and I will check it out.

On Validating Input and Assertions

Can you assume that all months have at least 28 days? How about all minutes will have 60 seconds?

Actually, in 1752, the month of September had only 19 days (of which, I am lucky enough to say that my birthday still occurred). As to the latter question, leap minutes can have 61 or 62 seconds. What does this mean for a programmer?

It means you cannot assume that all data is what you expect it to be. What happens to your software if a user says that an event in history occurred on September 25, 1752? Does your program accept it and move on? What about calculating the number of seconds since 1970? It seems that with leap seconds you could be incorrectly calculating this.

This topic can also point to the need to rely on existing libraries and reinforce the need to not try and roll your own implementation since it is very easy to miss details like these.

Tip 33 of The Pragmatic Programmer says that, “If it can’t happen, use assertions to ensure that it won’t.” I’m almost half way through with reading the book and I like the book’s high level discussions on code quality and programming methodologies.