How Web Developers Should Style Their Code?

Posted on July 3, 2013 by
singleimage

Each web developer creates code with different looks and methods to help them work faster and more efficiently. Components typically involved in coding styling include spacing, naming, casing and others.

Web developers are often advised not to become too rebellious and search on popular sources, such as github, to see popular coding styles. While how we style or format our code has no effect on the code’s inner working, web developers should write cleanly and elegantly.

In some cases, web developers need to break old habits and use more proper coding styles. Stubborn coders, who are resistant to things that can make them more efficient, better and faster, will eventually, go rigid and unable to swiftly adopt new trends and technologies in the community. It is a good idea to check our situation once in a while to see whether we need to break some bad habits and think outside the box to get more innovations. In a perfect world, all web developers should be able to fully comprehend codes written by others.

Understandably, coding style is a very personal matter and everyone prefers to use different styles in their codes. Coding styles developed from the way we learned how to code. Those who started from an IDE-based (Integrated Development Environment) may have more standardized styling code, while those who used plain editors tend to be more flexible.

Guidelines for coding styles can be helpful for web developers if they want their code easy to maintain and more readable to others’. Style may also change between web languages, as an example, it is less likely to carry over programming style with CSS, when developers code with JavaScript. Consequently, coding styles are determined by a number of small decisions, which are influenced by language requirements

These are factors that may affect coding style

Patterns to be avoided and used

Code grouping

Naming of functions and variables

Use of white space

Spaces and tabs for indentation

When and how to use comments

Achieving Uniform Coding Styles

Differences in coding style are often a challenge as a team work in web development projects. Due to time constraints, developer may deliberately try to avoid lengthy arguments. They may even argue that it’s improper to discourage expression and innovation. Some developers consider defined style guides are a way to force web developers to act uniformly. It’s not uncommon to see developers that turn rebellious when presented with defined style guides, as they believe that it’s impossible to do their job properly if people are telling them how they should work with codes.

We may liken this situation to an orchestra, which is consisted of individuals playing different musical instruments. Everyone will struggle so long as a few people want to do things differently. A web development team shouldn’t act like a band consisted of stubborn teenagers. It is not possible to accomplish much if people refuse to be one the same page.

Consequently, it’s highly advisable to use an enforced style guide and perhaps, include this as a requirement when hiring web developers for a project. By making early planning and preparation, achieving standardized coding style in a team shouldn’t be excessively difficult. There many issues we can avoid down the road if everyone agrees to write codes similarly.

Establishing and Maintaining Communication

Code used on web development project is not only meant to be executed by computers, but also for humans to read. Communication is an essential factor in any web development team to ensure effective cooperation between team members. Codes are also primary communication means between developers.

While computers don’t care how our codes are styled, other web developers on our team certainly do. When web developers are told to work with codes written by others, they are likely to add more comments. That’s because our brains may not be able to figure out these codes easily. In a web development team with different code styling, everyone constantly tries to parse others’ codes visually, before they understand it and work with it. On the contrary, productivity level will jump significantly when uniform code styling is implemented throughout the project.

When you start thinking of code as communication with other developers, you start to realize that you’re not simply writing code, you’re crafting code. Your code should clearly communicate its purpose to the casual observer. Keep in mind, your code is destined to be maintained by somebody other than you. You are not just communicating with other members of your team in the present, you’re also communicating with members of your team in the future.

I recently received an email from someone who is working on code that I wrote 10 years ago. Apparently, much to my shock and horror, my code is still being used in the product. He felt compelled to email me to say that he enjoyed working with my code. I smiled. My future teammate actually did appreciate the coding style I followed.

Leave Yourself Clues

“If you know your enemies and know yourself, you will not be imperiled in a hundred battles.” — Sun Tzu (in “The Art of War”)

Knowing yourself is important in life as well as coding. However, you’ll never know yourself well enough to remember exactly what you were thinking when you wrote each line of code. Most developers have experienced looking at a very old piece of code that they wrote and not having any idea why they wrote it. It’s not that your memory is bad, it’s just that you make so many of these little decisions while writing code that it’s impossible to keep track of them all.

Writing code against a style guide outsources that information into the code itself. When you decide when and where to use comments, as well as which patterns should and shouldn’t be used, you are leaving a breadcrumb trail for your future self to find your way back to the meaning of the code. It’s incredibly refreshing to open up an old piece of code and have it look like a new piece of code. You’re able to acclimate quickly, sidestepping the tedious process of relearning what the code does before you can start investigating the real issue.

As Chris Epstein once said during a talk, “be kind to your future self.” -Make Errors Obvious

One of the biggest reasons to have a coherent style guide is to help make errors more obvious. Style guides do this by acclimating developers to certain patterns. Once you’re acclimated, unfamiliar patterns jump out of the code when you look at it. Unfamiliar patterns aren’t always errors, but they definitely require a closer look to make sure that nothing is amiss.
For example, consider the JavaScript switch statement. It’s a very common error to mistakenly allow one case to fall through into another, such as this:

switch(value) {
case 1:
doSomething();

case 2:
doSomethingElse();
break;

default:
doDefaultThing();
}

The first case falls through into the second case so if value is 1, then both doSomething() and doSomethingElse() are executed. And here’s the question: is there an error here? It’s possible that the developer forgot to include a break in the first case, but it’s also equally possible that the developer intended for the first case to fall through to the second case. There’s no way to tell just from looking at the code.

Now suppose you have a JavaScript style guide that says something like this:

“All switch statement cases must end with break, throw, return, or a comment indicating a fall-through.”
With this style guide, there is definitely a stylistic error, and that means there could be a logic error. If the first case was supposed to fall through to the second case, then it should look like this:

switch(value) {
case 1:
doSomething();
//falls through

case 2:
doSomethingElse();
break;

default:
doDefaultThing();
}

If the first case wasn’t supposed to fall through, then it should end with a statement such as break. In either case, the original code is wrong according to the style guide and that means you need to double check the intended functionality. In doing so, you might very well find a bug.

When you have a style guide, code that otherwise seems innocuous immediately raises a flag because the style isn’t followed. This is one of the most overlooked aspects of style guides: by defining what correct code looks like, you are more easily able to identify incorrect code and therefore potential bugs before they happen.

Devil In The Details

In working with clients to develop their code style guides, I frequently get asked if the minutia is really that important. A common question is, “aren’t these just little details that don’t really matter?” The answer is yes and no. Yes, code style doesn’t really matter to the computer that’s running it; no, the little details matter a lot to the developers who have to maintain the code. Think of it this way: a single typo in a book doesn’t disrupt your understanding or enjoyment of the story. However, if there are a lot of typos, the reading experience quickly becomes annoying as you try to decipher the author’s meaning despite the words being used.

Coding style is a lot like that. You are defining the equivalent of spelling and grammar rules for everyone to follow. Your style guide can get quite long and detailed, depending on which aspects of the language you want to focus on. In my experience, once teams get started on coding style guides, they tend to go into more and more detail because it helps them organize and understand the code they already have.

In art, numbers are usually chaotic and serve a visual purpose. But you need order in your code. (Image credit: Alexflx54)
I’ve never seen a coding style guide with too much detail, but I have seen them with too little detail. That’s why it’s important for the team to develop a style guide together. Getting everyone in the same room to discuss what’s really important to the team will result in a good baseline for the style guide. And keep in mind, the style guide should be a living document. It should continue to grow as the team gets more familiar with each other and the software on which they are working.

Tools To Help

Don’t be afraid of using tools to help enforce coding style. Web developers have an unprecedented number of tools at their fingertips today, and many of them can help ensure that a coding style guide is being followed. These range from command line tools that are run as part of the build, to plugins that work with text editors. Here are a few tools that can help keep your team on track:

Eclipse Code Formatter

The Eclipse IDE has built-in support for code formatting. You can decide how specific languages should be formatted and Eclipse can apply the formatting either automatically or on demand.

JSHint

A JavaScript code quality tool that also checks for stylistic issues.

CSS Lint

A CSS code quality tool by Nicole Sullivan and me that also checks for stylistic issues.

Checkstyle

A tool for checking style guidelines in Java code, which can also be used for other languages.

These are just a small sampling of the tools that are currently available to help you work with code style guides. You may find it useful for your team to share settings files for various tools so that everyone’s job is made easier. Of course, building the tools into your continuous integration system is also a good idea.

Conclusion

Coding style guides are an important part of writing code as a professional. Whether you’re writing JavaScript or CSS or any other language, deciding how your code should look is an important part of overall code quality. If you don’t already have a style guide for your team or project, it’s worth the time to start one. There are a bunch of style guides available online to get you started. Here are just a few:

jQuery Core Style Guidelines

Google JavaScript Style Guide

Google HTML/CSS Style Guide

Principles of Writing Consistent, Idiomatic JavaScript

Principles of Writing Consistent, Idiomatic CSS

GitHub Style Guide (Ruby, HTML, CSS and JavaScript)

It’s important that everybody on the team participates in creating the style guide so there are no misunderstandings. Everyone has to buy in for it to be effective, and that starts by letting everyone contribute to its creation.(cp)

Author :

  • Subash