Someone said to me recently “I don’t care what the code looks like, as long as it works.” This offended me because I take pride in making my code look nice and easy to read. Plus it makes me happy to develop clean code. But why should you care?
I was on a project that has been around for over ten years. We had a joke on the team when someone new to the team asked “Where are the requirements?”, I would reply, “The code is the requirements.”
However, I was not really joking. It is our job as programmers to express the intent of the code so the next person who looks at it knows exactly what the code is supposed to do.
Not only should we write simple-easy-to-understand-code. We should also pay attention to the design of our code. Bad designs are hard to work with.
Before the mass production of the automobile, a buyer would go into a shop and talk to a couple of mechanics that would craft a car from the ground up.
Some car companies still make cars like this today. Say a shop built me this beautiful feature rich car. But when I take it in to replace the air filter the mechanic tells me. “Well we finally found the air filter, it is hard to get to so we will have to break down the engine to change it”. My $50 fix quickly turns into hundreds of dollars in labor. All because the designers of my car didn’t pay enough attention to where they were putting the air filter.
This happens in software all the time. If we don’t pay enough attention to the design of our classes ( “air filters” ), when we want to make a small change it requires a large refactor (breakdown of the engine) which drives up the cost to change.
Programming languages like C# make it real easy to write code that is almost like reading plain English. By coming up with good metaphors for your class and method names you can tell the stories of your system through code. This will make it easier for other developers (or yourself) to pick up where you left off.