Code Style Guides - Consistency is King

There have been countless flame wars online about the details of the guidelines that appear in various Code Style Guides. Some of the most famous are the tabs versus spaces arguments, whether or not to put curly brackets {} each on their own line, whether you should even use the curly brackets {} for one line actions in if statements.

I am here to say that the only thing that matters in the style of your source code, other than syntactically correct code, is consistency. When a codebase has internal consistency, developers new to it are more easily able to pick up the meaning of the source code contained within instead of having to first understand why the different styles in different sections matter, or not.

The overwhelming rule that I try to follow when it comes to a style guide is that “the source code should look like a single developer wrote all of it” when in fact many developers have written different sections.

Tags:

Related Posts

Jun 10, 2014
3 minutes

5 Ways to Do SCRUM Poorly

As a developer that frequently leads projects and operates in various leadership roles depending on the current project lineup, the Agile development methodology is a welcome change from the Waterfall and Software Development Life Cycle approaches to software development. SCRUM is the specific type of Agile development that I have participated in at a few different workplaces, and it seems to work well if implemented properly. However, there are several ways to make a SCRUM development team perform more poorly than it ought. The top 5 I have seen include:

#rant #management #agile
Read More
Apr 16, 2014
2 minutes

Top 5 Ways to Make a Developer Your Enemy

Developers are known to be some of the most finicky employees you will encounter in the workplace. However, this is a list of things that will annoy or infuriate developers and non-developers alike.

  1. Have the IT Manager send an email to all staff saying that all computers will have a keylogger installed. – This one is wrong on so many levels, the least of which is that it shows how little faith the company has in its employees and breeds mistrust of authority.
  2. As a Manager or Team Lead, take ideas and suggestions from meetings with your team, and pass them off to upper management as your own. – This just reeks of someone that is only in it to gain more and more power.
  3. As a Manager, don’t take the heat when things go wrong and blame the lowest-level employee instead. – I’ve seen senior management that is supposed to keep track of projects, ignore the project, and when it is the due date, blame those doing actual work on the project, throwing them under the bus.
  4. As a new employee, on your second day of work, tell anyone that will listen or is within earshot that you are able to rewrite the entire codebase in three short months. Bear in mind, this codebase is over 7 years old and has a team of more than 20 developers working on it, but of course the newbie can rewrite the entire thing in no time flat.
  5. As Management, when a developer hands in his/her resignation, schedule a meeting to try to first place a guilt trip on said employee to convince them to stay. If that doesn’t seem to work, then threaten to give the employee negative referrals if they don’t rescind the resignation and continue working for the company. Keep in mind that this occurred in a right to work state, meaning that there is no agreement in place that the employer would not wait a day or week or month and fire the employee without cause, just out of spite for wanting to work elsewhere.

These are just some of the things that will anger a software developer, so, be aware to avoid these if it matters at all to you.

#rant
Read More
May 23, 2014
2 minutes

Avoid SiteCatalyst's useForcedLinkTracking and target="_blank"

All sites rely upon some third party analytics software to track at the very least the number of visitors to a site. Many sites use Google Analytics, which provide much more information that just the number of visitors. Another option that some of the bigger sites use is Adobe Analytics, aka SiteCatalyst to enable more custom tracking options that are not evident through the Google Analytics interface.

One feature of SiteCatalyst is that it allows you to set an option useForcedLinkTracking that will track every link on your site for clicks whether or not you have setup custom tracking for the links or not. Effectively what the code does is create a JavaScript event handler to intercept all click events on the <a href="http://url.com">Link</a> hyperlinks. Once they are intercepted, SiteCatalyst sends its tracking information to its servers and then procedes to attempt to make sure that the link functions properly. Unfortunately, in some versions of the SiteCatalyst code, it attempts to create a synthetic click event that works in many cases. However, if you are using Safari with the popup blocker turned on, and a target="_blank" in the hyperlink, then it will trigger the popup blocker, which simply ignores the click, and the user sees nothing happen at all. In order to fix it, hopefully the latest version of the SiteCatalyst code will handle it, turn off useForcedLinkTracking, or, as the very last resort, convert the <a /> links to another type of element and use JavaScript to open the new window manually when listening for the click event on the new element. It seems this works all the time, but it will prevent SiteCatalyst from tracking those clicks.

#javascript #rant #sitecatalyst
Read More