Coding consensus: 9 popular programming conventions

When it comes to writing code, programmers can often differ over what conventions should rule. Here are a number of conventions, though, where there seems to be some consensus

Close of picture of computer code

Programmers usually adhere to certain conventions when writing code, such as using spaces instead of tabs (or vice versa) when indenting code. These conventions can differ across programming languages and organizations and even from developer to developer. But which conventions are most commonly followed? A new tool that grew out of a recent GitHub data challenge now helps to identify the most popular coding conventions. By looking at millions of recent GitHub commits, Popular Convention by JeongHoon Byun identifies the rates at which programmers are following common conventions for a number of popular programming languages. Using this tool, here are 9 coding conventions that developers seem to (almost) agree on.

Pie chart showing that spaces are chosen for code indentation 84% of the time, compared to 16% for tabs
Credit: ITworld/Phil Johnson
Space over tab

Whether to use spaces or tabs when indenting code is an age old debate. However, based on over 7 million GitHub commits for 7 different languages (JavaScript, Java, Python, Scala, Ruby, C# and PHP), spaces are clearly chosen far more often than tabs. The language using spaces instead tabs the most was Scala (96%), followed by Ruby (95%), Python (95%), C# (82%), JavaScript (81%), Java (74%) and PHP (70%).

Pie chart showing that 92% of the time programmers set maximum line width to 80 characters, 6% of the time 120 and 2% of the time 150
Credit: ITworld/Phil Johnson
Maximum line length 80 characters

A maximum line length of 80 characters has a long history in computers and programming, dating back to IBM punch cards and early monitors. Nowadays, though, with bigger and higher resolution monitors, longer line lengths are easily possible. However, the convention of keeping lines of code to no more than 80 characters clearly persists, as these data show. 92% of the over 5 million GitHub commits for six different languages (Java, Python, Scala, Ruby, C# and PHP) adhered to this convention, with 6% using a 120 character limit and just 2% using a 150 character limit.

Pie chart showing that 98% of the time programmers omit empty parameters when defining functions or methods without arguments in Ruby, only including empty parentheses 2% of the time
Credit: ITworld/Phil Johnson
Omit empty parentheses

Normally, when defining or calling functions or methods, arguments are wrapped in parentheses. However, some programming languages make the use of parentheses optional. While some programmers will prefer to still include them for readability, for Ruby developers there is a clear consensus that, when there are no arguments (hence the parentheses would be empty) parentheses should omitted. 98% of the 239k commits in the GitHub data omit parentheses in this case. So

def some_method
    # do something...
end

is clearly preferred over

def some_method()
    # do something...
end

Pie chart showing that 94% of the time programmers don't put spaces around argument definitions in function declarations, and 6% of the time they do
Credit: ITworld/Phil Johnson
No spaces around argument definitions

Some developers feel that putting an extra space around the arguments in a function declaration improves code readability. For example:

function fn( arg1, arg2 ) {
    // ...
}

However, 94% of the almost 1.5 million GitHub commits for JavaScript, Java, C#, PHP code did not put a space around the arguments, like so:

function fn(arg1, arg2) {
    // ...
}

Clearly, no spaces is the preferred convention.

Pie chart showing that 92% of the time programmers choose commas last of ver comma first (8% of the time) when delimiting lists
Credit: ITworld/Phil Johnson
Comma last, not comma first

When defining a series of values over multiple lines, such as in an array, some people advocate putting the comma between values at the beginning of each line to improve readability, debugging and maintainability.

var obj = {
    foo: 1
  , bar: 2
  , baz: 3
};

However, the convention, at least within the JavaScript world, seems to be to put commas at the end of lines, since 92% of the 1 million JavaScript commits in GitHub went with comma last over comma first.

var obj = {
    foo: 1,
    bar: 2,
    baz: 3
};

Pie chart showing that Camel Case is used when naming functions and methods 87% of the time versus Snake Case (11% of the time) and Pascal Case (2% of the time)
Credit: ITworld/Phil Johnson
camelCase rules over snake_case

Programmers agree that one of the hardest things they have to do is name things, like variables, classes and methods. However, what they often don’t agree on is the type of casing to use when naming things. For example, should they use camelCase, snake_case or PascalCase? When it comes to naming functions in PHP or methods in Scala, however, there does seem to be a consensus: 87% of the 237k commits in the GitHub data followed the camelCase convention, with snake_case (11%) and PascalCase (2%) lagging far behind. ALL_CAPS_SNAKE_CASE and Snake_Pascal_Case were also used, but in well under 1% of these commits, so they are not shown in this chart.

Pie chart showing that 70% of the time programmers don't put curly braces on their own lines; 30% of the time they do
Credit: ITworld/Phil Johnson
Curly braces dont get their own lines

When writing blocks of code, such as classes, methods or control structures, programmers have to decide whether to put curly braces on their own lines, or, for opening braces, on the same lines as the declarations. That is

class Foo
{
    // ...
}

or

class Foo {
    // ...
}

Some find putting braces on their own lines is cleaner and clearer, while others find it excessive. Based on 1.5 million GitHub commits for Java, C# and PHP, curly braces were put on a new line only 30% of the time, so the clear convention is to not put each curly brace on a new line.

Pie chart showing that 57% of the time JavaScript programmers choose single quotes, and only use double quotes 43% of the time
Credit: ITworld/Phil Johnson
Single quotes instead of double quotes

When using strings in JavaScript, you can wrap them in either single or double quotes. For example

var foo = 'bar';

versus

var foo = "bar";

The choice of which to use essentially comes down to personal preference. Some prefer double quotes since with single quotes you have to escape any other single quotes within the string, such as in contractions ('That\'s it!'). Based on 1.6 million commits of JavaScript code in GitHub, while the choice between the two is close, single quotes are preferred more than double quotes 57% of the time to 43%.

Pie chart showing that 53% of the time programmers put constant names in all capitals, as opposed to not putting them in all caps 47% of the time
Credit: ITworld/Phil Johnson
Constant names in all caps

Traditionally, many programmers have put the names of constants in all caps as a way to make their special nature more obvious to anyone reading the code. However, some find that to be a bit of a coding anachronism. Based on over 350,000 GitHub commits of Java, C# and PHP code, all caps is still the convention - but not by much (53% to 47%).