GEOG 863
GIS Mashups for Geospatial Professionals

4.5.5 Style guides

PrintPrint

In the previous sections, we saw that both linting and beautifying tools can be customized based on personal preference.  Application development often involves multiple coders contributing pieces to the end product.  Editing application code, whether fixing bugs or adding additional functionality, is much easier when all of the code is formatted in the same way.  When code jumps between different formats (i.e., style rules), the person trying to interpret the code is forced to waste valuable time adjusting his/her mindset to the different formats.  And even in organizations in which team coding is not employed, it is rare that an application will only ever be modified by the original author.  Coders go on vacation, leave the company, etc.  For these reasons, many organizations go to the trouble of constructing a style guide – a set of rules that all of their coders will follow.  Here is a JavaScript style guide used at Google:

Google JavaScript Style Guide

Many of these rules are fairly advanced, but there should be at least a few you can grasp.  For example, the guide's authors specify that all statements must be ended in a semi-colon even though you might be able to get by with omitting them.  Multiline string literals should be constructed using string concatenation rather than the line continuation character.  Under the Code formatting heading, you’ll find some of the personal preference items we discussed in the beautifying section.  Opening braces should be found on the same line as what they’re opening, property settings in an object definition should be indented two spaces, etc.

If you work in an organization that already does JS development and you’re going to be joining a development team, you should look into whether there is a style guide you should be following.  If you’re just starting a new team, it might be a good idea to put some thought into creating a guide.