Coding styles comparison in the Open Source Software world

Posted on 2010/12/28

23


While looking for existing C coding standards I discovered that the GNU and Linux projects officially suggest very different styles. Inside the Linux kernel documentation, Linus Torvalds goes so far as to mock GNU coding standards:

First off, I’d suggest printing out a copy of the GNU coding standards,
and NOT read it. Burn them, it’s a great symbolic gesture.

At this point I wanted to understand the difference between the coding styles of established open source projects. When I say “styles” I mean mainly the source code appearance, and the standards that help to read and maintain the code. Here’s a list of coding styles that I read:

Many stylistic aspects can’t be compared directly because they are different languages, but it was interesting to map some of them, for example indentation and maximum line length:

indent line length
Linux 8 char tabs 80
GNU 2 spaces N/A
Qt 4 spaces 100
Java 4 spaces 80
Python 4 spaces 79
Gnome 8 char tabs N/A
Mono 8 char tabs 80
Ruby 2 spaces 80

About indentation, the styles describe differently the indentation of function declarations from the indentation of branches (thanks to TaQ for the Ruby suggestions and to JoeT for the correction on the Java example):

branches functions
Linux if (foo == 0) {
→bar();
→foo = 1;
}		 int foo()
{
→return 0;
}
GNU if (foo == 0)
→{
→→bar();
→→foo = 1;
→}		 int foo()
{
→return 0;
}
Qt if (foo == 0) {
→bar();
→foo = 1;
}		 int foo()
{
→return 0;
}
Java if (foo == 0) {
→bar();
→foo = 1;
}		 int foo() {
→return 0;
}
Python if foo == 0:
→bar()
→foo = 1		 def foo():
→return 0
Gnome if (foo == 0) {
→bar();
→foo = 1;
}		 int foo()
{
→return 0;
}
Mono if (foo == 0) {
→bar();
→foo = 1;
}		 int foo()
{
→return 0;
}
Ruby if foo == 0
→bar
→foo = 1
end		 def foo
→0
end

The naming of variables and functions is one of the first things that is apparent while looking at sample code, and sometimes helps to understand the code:

var names const names func names
Linux lower_case UPPER_CASE lower_case()
GNU lower_case UPPER_CASE lower_case()
Qt mixedCase mixedCase mixedCase()
Java mixedCase UPPER_CASE mixedCase()
Python lower_case UPPER_CASE lower_case()
Gnome lower_case UPPER_CASE lower_case()
Mono mixedCase N/A CamelCase()
Ruby lower_case UPPER_CASE lower_case()

I think that one of the reasons that the coding standards are so different is because the principles that they follow are very subjective: readability, clutter, clarity, they depend on the developer that writes or reads the code. The styles also have to find a compromise between readability and code size: for example mixed case naming occupies less characters than using lower case with underscores, and indenting with tabs occupies less bytes than using spaces; but these advantages are quite negligible in my opinion. The aspect that is important for me is consistency between source files in a project: it helps to read the code the first time, it is useful to understand coding patterns and to follow the execution while debugging. To help with consistency, there’s a tool called indent that helps to enforce some of the coding styles; the default settings of indent enforce the GNU coding standards for indenting. The Linux kernel contains its own tool called Lindent, that is basically a script that calls indent with some parameters. I think it should be a good practice to select a style for a project, stick to it and use tools to enforce the styles before committing a change in the source code repository.

Tagged: , , , , , , , , , , , , , , , ,
Posted in: Software