Organization: How cars and software development relate

It may go without much notice to those who use applications, but a lot of planning went into the development of it. There is time spent on the algorithms efficiency, the overall efficiency, the usability of the application and much more than I can relate in a paragraph on a blog. It would also probably surprise some of you that as much as thirty to fifty percent of my time is spent on organizing and updating old information before I code.

I am a big fan of open documentation, and self documenting code to help minimize what I need to write. Things like naming a variable a is often the wrong thing to do when it is related to the count of asteroids in the solar system, because it doesn’t communicate any information to the user, where as the name the_number_of_asteroids_in_the_solar_system is way too long and just makes it difficult to print your application out cleanly. I spend a good portion of my time going back through my code and making sure that my variables are in-between those two, while usually on the lighter side because of how I was taught to code.

Another great example of organizing code is the placement of it. When you are learning to write C programs you are taught to declare your functions globally, and while this is not an issue on smaller labs it becomes an issue once your functions get into the double digits and your pages begin to extend into infinity. A simple fix for this is to declare your functions at the header of the function that you are using it in, and although this is a quick way to add lines to your code, the readability goes through the roof and you should always choose readability over terse code, unless you are trying to enter into an obfuscated contest.

Where to put your functions declaration is one thing but you can also control where to put your definitions. When you have your code organized willy nilly you will find yourself scanning more than actually paying attention to the code, and any readers of your code will often become frustrated by your code if they don’t find what they want quickly and easily. I have seen many different routes to organizing code but prefer to group together functions in the order they are called in order to ensure that the reader is only reading no more than the next function in order to find where the calls are.

As you may have noticed, I have an obsession with tools. My dad is a mechanic, and has sold me on the idea that if I have the right tool for the job I will always be prepared when crazy things happen. He has thousands of tools, hundreds of wrenches, dozens of types and is able to diagnose issues with cars in minutes or hours when others have taken hours or days. I like to believe that I am the equivalent when it comes to code, and to that accord it is important that, just as with my dads diagnosis, a spark plug is where the spark plug goes and the O2 sensor is in the right spot. Code evolves more than cars do. Most every car has the same parts and the next one, and for the most part they are in the same areas; they are organized in order to ensure that construction and maintenance are not a drag on the manufacturer, owner or maintainer and you should write code with the same in mind.