2 min read

The Benefits of Using Style Guides When Writing Code

Style-Code

Working as part of a group of developers can have its own special complications beyond the usual programming hurdles. Like travelers on a journey, two developers might take wildly different paths to the same destination. One might declare a variable as myVariable, while the other might call it my_variable. One might prefer an empty line between function declarations, and the other might not.

These may sound like trifling details, but when working on a large project these minor variances can quickly become major inconsistencies. Consider one simple PHP function written by two different developers:

Style Guide

As you will notice, there are numerous differences in code styles here. Some approaches are more efficient, while some are a matter of taste. For example, Programmer #1 begins his function with a block-style comment, while Programmer #2 prefers a simpler inline double-slash. Programmer #1 uses a two-space indent, and #2 appears to be using his tab key.

Both examples are perfectly valid and probably fine for small projects, but try to imagine these inconsistencies spread across hundreds of files and thousands of lines of code. If a team of developers is not working under a style guide, shared resources may become muddled as individuals struggle to remember the variable or file they are supposed to reference.

Am I supposed to include className.php or class_name.php?

Is the site session called site_session or siteSession?

Additionally, code quickly becomes confusing and hard to interpret, particularly in languages like PHP or JavaScript which lack strict data typing. Can you tell, at a glance, if $myVariable is supposed to be a constant? You might be able to, if everyone in your group agreed to write constant variables in capital letters: $MY_VARIABLE. Is it a number, a string, or an array of values? Maybe it's a function argument, or a global.

As you can see, proper naming conventions can greatly improve group efficiency. Different companies or groups will have specific established standards, but what is most important is consistency. Decide on a set of rules that each developer will abide by, and enforce these standards during your normal code review process.

If you aren't sure where to start, here are a few general styling rules to consider:

  • Do you use the tab character or spaces for indenting? How many spaces deep is each line?
  • How do you handle comments? Is there a special way to explain functions?
  • Spacing between lists of variables.
  • Naming conventions for variables, functions, classes, and files.

Style guides are also going to be different between languages. If you do not want to make your own, you might consider using some established guides developed (and used) by major players. Here are a few that are commonly used:

  1. Google styleguides
  2. Microsoft C#
  3. Oracle Java
  4. Pear PHP coding standards
  5. GitHub StyleGuide

Finally, there are a handful of software tools that can automate the detection of common style violations. A good one for general web development is PHPCodeSniffer. Lint is also a very old syntax checker which has been adapted for a variety of languages, and is even used in some websites which offer online code verification. Take a look.

Standardized coding is an important part of professional development and should be implemented as early as possible to avoid later confusion. When developing a style guide, try to involve your entire team. Remember that standards cannot be enforced unless everyone agrees on what that standard is.

Does your team have a style guide? Tell us your experiences.


Related Posts

2 min read

How to Increase Private Equity Valuation through Website Development

Investors, whether venture capitalists, private equity firms, or angels are all looking for the same thing – where to invest their funds to maximize their returns. Investors are looking for high...
2 min read

What is the Customer Experience Journey

Today, businesses have high expectations for a great experience when working with other businesses to buy products and services. The customer journey is the complete sum of that experience they go...
2 min read

Why Customers Don't Want to Talk to You

It’s all in the title: Customers don’t want to talk to you.
4 min read

Measuring 'Voice of the Customer' to Create WOW Web Portal Experiences

Let's talk about How to measure the Voice of the Customer to create WOW experiences on your web portal. A strong understanding of who your customers are, what they enjoy, and what they struggle with...