Over the past week I have had a couple conversations with a new co-worker of mine, Kayla, about the implications of code standards, practices, conventions, or choose another complicated noun to insert here. When joining a new team you always want to be respectful to previous habits and conventions when styling and organizing your code. Naturally I didn't want to be "that guy" who just did things wrong. While each informative banter concluded differently with equally different subject mater, in the end of each conversation we essentially arrived at the same conclusion: there is no right or good way to build a project; it all depends on the eye of the beholder.
Now what does this mean? Well let me give you an example as it pertains me to and my habits; good and bad. Through out my professional career one thing that I have always taken pride in is the neatness and quality of my code. I have even received numerous compliments from potential employers on the neatness and organization. For myself, there is nothing like seeing the systematic nesting flow of HTML and CSS within my files.
Notice how I said neatness and organization, and not efficiency. I can even say that upon peer code reviews that I don't always write CRUD code. Sometimes I don't think things all the way through because I get lazy or get in a hurry. In this scenario, think of someone who was unfamiliar with the project and was needed to make some changes. According to a study done by the University of Maryland, "about 40-50% of the effort on current software projects is spent on avoidable rework." That could be four to five thousand dollars saved on a ten thousand dollar bug fix. At that point, who cares if my code is a work of art; art can be expensive if it is careless.
Your living space
For most of us programmers and developers, we love our jobs. Just about every day of our lives we have our faces in our computer screens, sucking down some Code Red (or other stimulating beverage of choice) and write line after line. Lets face it, again for most of us we eat, sleep, and just live development.
For a moment lets think of our code as our bedrooms. Each item has it's place; our bed has a place of prominence, and our clothes are located in or around or dresser/closet, and so on and so forth. However if one thing is out of place, it is next to impossible to find. If we can't find it we tear the place apart; more often than not leaving the room in a worse state than we found it. An intricate function or library can be the exact same thing. If our indentations are off we cannot find where a function begins or ends, function chaining can be next to impossible to sort, and we could even possibly comment out a variable that the entire code set needs to run. And just like our room, if we cannot find what we are looking for, a weird concoction of line comments and copy/pastes ensues.
Now lets take this a step further. Remember that feeling as a child when your mother would come into your room and attempt to clean therefore moving all of your things that only knew where they were located? The same can be said if one or more developers cracks the lid on your code. I'm sure that we have all been in the same situation: where we quietly curse the previous developer and question their methodology and reasoning for doing everything they did.
This is why habits followed by documented reinforcement are important. Take this post by NetTuts for instance. While all of the suggestions cited here are great for a foundation, if one developer follows 8 out of the 15 best practices, and another developer follows a 7 different practices, the code just won't look the same.
Invest for those of us who don't
Being a developer in multiple disciplines and languages, I have somewhat of a rare ability to be able to take a step back in scour the landscape of development as a whole. One thing that I can safely conclude is that we as developers while creatures of habit, will go out of our way to avoid doing any other additional work; even it requires several hours worth of work. My wife would call that being lazy. Larry Wall, author of the PERL programming language said the three great virtues of a programmer are laziness, impatience and hubris. I think that this probably comes to no surprise to no one. Cory House from Pluralsight says that laziness is usually derived from not wanting to put forth the effort at the beginning of project with the intent to clean it up later. But what we fail to realize that this lapse in quality will only have a ripple effect down the road. Developers almost expect their predecessors to compose thorough and soundly correct code so further down the line we can make a couple bug fixes and move on.
I have found that the absolute kiss-of-death comment that any developer can give about another developer is when someone, "Pulls a [insert a name]." Cory House also labels this as "becoming a verb." There is nothing worse than leaving a legacy laced with negative undertones and teeth-grinding hatred. This only leads back-stabbing camaraderie and people just despising the air you breath. No one wants that.
So what I would do...
While I am not in the business of getting up on my soapbox and trying to convince you why my opinions are better than someone else's, I would simply give you a few things I would do; and also because the subject matter of this post demands it.
Have a plan
While this may sound like I ripped this off of a motivational speaker of financial advisor, you always need to have a plan when you are scaffolding out a website or application. Functions go here, routes go there; its more of a personal statement of organization than anything. Now this is important, your plan can change. Things like scale and feature requests can quickly derail the perfect plan. But never fear! If you have invested the time and organized your code in the appropriate directories and libraries, these changes will be easier to bear.
Punctuation and space
The item that I am most particular about (and I can get somewhat heated about) is indentations and punctuation. Functions, arrays, and even SASS nodes all deserve the time and care to have their children and parent elements to receive the appropriate indentations; the further your traverse within a function, the more it should be indented. It's that simple. This allows your IDE to copy and paste code snippets from one file to another, it allows you to quickly spot parameters to be used within further functions and callbacks, and just simply looks better.
Punctuation plays a separate yet equally painful part of a developers life. Even when using CSS, which can be debated as the most forgiving language of all, you need to place semicolons at the end of every line or it won't work. While languages like PHP don't really care about how the code is structured as long as it is punctuated correctly, other languages such as Ruby and Python utilizing indentations as it's own form of punctation; failure to do so results in bugs and errors.
Write it down
I'm sure some of my previous co-workers would laugh if they read this part due to the overwhelming irony but realistically it is just as important. Documentation is one of the easiest yet most important of working on a application with a large team. A centralized location for dependencies as well as basic a basic description of application infrastructure helps speed up with the learning curve/ramp-up time when imploring a the services of another developer.
