The Pragmatic Programmer

I just finished reading The Pragmatic Programmer by Andrew Hunt and David Thomas. Here's a few things that I learned while reading this book.

Design by Contract

A code contract specifies how a function should work by clearly stating the preconditions and postconditions of that function. This is an important concept for a few reasons. 1) It is testable. If I know exactly what the pre and post conditions of a function are, it is very easy to test if the function is working as stated. 2) Other people know exactly how your function should work. 3) If the contract is stated clearly enough, it will be very easy to tell who is at fault when the function fails. 

When to use Exceptions

This section explains that Exceptions should only be used in the case of, well, something exceptional (i.e. something that doesn't normally happen). They should not be a part of the normal flow of our software. With each exception, control is transferred from your function to somewhere else. The context switching involved in this is expensive and hard to maintain. Eventually, this style of code will turn into spaghetti code.

Decoupling and the Law of Demeter

This section explains how to decouple classes and methods from each other via the Law of Demeter, which says that a function should only call 1) itself, 2) parameters, 3) objects it creates, 4) functions of the same class. If we write code following these rules, we will avoid coupling classes together. Of course this method has exceptions, such as static functions. It is extremely difficult to take in a static object as a parameter. One options is to create a wrapper class that can be instantiated. This will be useful for testing and decoupling.

Pride and Prejudice

This is a simple concept that a Developer is to be proud of his work. The pride that we have in our work should express itself with our signature at the top of every file which we own. This is an intimidating concept for those that like to remain anonymous. However, if your code is tested, comment, and decoupled, your signature will stand as a symbol of quality.

Domain Languages

This section explains that when we need a specific way to describe some data or problem, we should create a Domain Specific Language. On example is makefiles. There is a domain specific language used for writing makefiles and there is a parser that interprets them. The authors simply state that if we need a language that is closer to our problem, just create it. However, I don't agree with this for a few reasons. 1) DSL's are an investment. The parser for makefiles didn't come together overnight. It took a lot of time. 2) It's hard to disseminate and maintain them. If you start using some language you just made up for a project, you are the only person that knows about it. If you leave the project or worse, get hit by a bus, your team is in trouble. 3) There are already a lot of great languages for describing data, XML, YAML, JSON, to name a few. These are standards that are very well known and have very developed toolsets to accompany them. For these reasons, I don't agree with developing a DSL whenever needed.