Recently, in several different teams, I found that their coding standards vary greatly in the use of spaces. This piqued my curiosity, because I had always thought that there should be a universally acknowledged best practice for the use of spaces in code formatting. But in real-world development, such uniformity does not seem to have emerged.

Current Status

First, let's look at the style conventions for Java code in most Java IDEs.

Here is an example:

public class Example {

public static void main(String[] args) {
    int answer = 2 + 4 * 6;
    for (int i = 0; i < 5; i++) {
        doSomething();
    }
    System.out.println("The answer is " + answer);
}

    private static void doSomething() {
        // something
    }
}

Note that this is the most common style among Java programmers and in other C-like languages.

There are no spaces on either side inside the parentheses. Only when the parenthesis is preceded by a keyword such as 'for' or 'while' does a space appear between them, but there is no space between a method name and the following parenthesis. However, there is always a space before the opening curly brace (which usually appears at the end of a line). Mathematical operators are always surrounded by spaces. And there is no space before a semicolon.

If you read code often, you may think this is a very natural arrangement, but if you are not a programmer, you might find these rules too arbitrary, with many inconsistencies, special cases, and points open to debate.

Please leave more space for your code

In my current development project, there are two main development teams in the company: one is the Load Test Products (LTP) team, and the other is the Functional Test Products (FTP) team. Both teams follow certain coding style conventions, and both are particularly generous in their use of spaces, as in the following code snippet example:

public class Example
{

    public static void main( String[] args )
    {
        int answer = 2 + 4 * 6;
        for( int i = 0; i < 5; i++ )
        {
            doSomething();
        }
        System.out.println( "The answer is " + answer );
    }

    private static void doSomething()
    {
        // something
    }

}

This style makes the code look less dense and more uniform (for example, there is no space before opening parentheses, and there are spaces on the inner left and right sides of all parentheses, curly braces, and square brackets)! I'm not saying this is better or worse than the previous style... it just makes it easier to distinguish words. The cost is that a single screen can display less code.

Although each coding style has its own advantages and disadvantages, what surprised me was that the FTP development team eventually decided to switch to the most common coding style mentioned earlier. They believed the change was worthwhile, and they even had discussions about it, so I believe they considered the change important. Their decision was not based on whether this style is better than that one... I think it mainly focused on who is accustomed to this style, since most of our products are open source, which is an important reason: it makes it easier for programmers in the community to contribute code.

In my team, the LTP team, we still stick to our style and have no intention of making any changes. At least for me, this is a decision based on technical considerations: if another coding style does not show any advantage (our project has little need for open-source contributions), why switch to another style?

Rules Need to Be Unified

I have been contributing code to open-source projects, such as the Ceylon programming language, and I was very surprised that they did not follow any coding style at all. You can write code in any style you like.

Some programmers who have been intimidated by the sheer volume of coding standards in some companies might like this, but I believe that without a set of coding standards, your project's code is likely to fall into formatting chaos. Every code contributor brings his or her own unique code style when submitting code, which is not surprising; the result is that all the code is varied, and you can see multiple different styles in the few lines of code below:

while (exists cell = iter) {
        if (exists elem = cell.element,
        elem==element) {
            last = cell;
        }
        iter = cell.rest;
    }
}

if (exists cell=last){
    cell.element=replacement;
    return true;
}
assert (0<=index<length);

The main question I want to raise is: is coding style really an important development practice? How much impact does it have on programmers' efficiency in developing software?

I believe this question is linked to another similar question: does code formatting affect code readability?

Code Formatting Affects Code Readability

I think this question is very easy to answer! Of course it does. Visually scan the following two pieces of code line by line (taken from the Ceylon project), and you will easily feel which one is easier to read. – CeylonCreate)?

function validModuleNameChar(Character c)=>c.letter||c.digit||c in ['_','.' ];
if (!trimmedName.empty,
    validModuleNameFirstChar(trimmedName.first else 'X'),
    trimmedName.every(validModuleNameChar),
    !(trimmedName.split('.'.equals,true,false)).containsAny(ceylonKeywords.chain {""})) {
    return trimmedName;
}
function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

The difference may be small, but if you spend a lot of time reading a lot of code all day, the difference becomes huge.

Lessons Learned from Ordinary Text Writing

When talking about code readability, perhaps we should look at people's more ordinary ability to read text. This ability has developed over thousands of years, so a better solution should have been worked out!?

In 'ordinary' English, you can see the conventional use of spaces, but you don't see writers discussing whether they should use spaces around parentheses! So what would it look like if code were written like 'ordinary' English?

Let's return to the simple example above:

function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

Most things in code are the same as ordinary English sentences. You use parentheses to 'group' certain words. You use spaces between words and symbols—here we find a place different from common coding habits: when we call a method, there is no space between the method name and the following parentheses, and no space is left after the dot operator.

I can understand why there are no spaces in these places, because these parentheses or dots in the code represent a kind of 'ownership' relationship or an association. But is it really necessary to squeeze out that bit of space to represent this relationship? Doesn't it feel very clear when we look at the example code above?

Another thing that does not exist in ordinary English is nested expressions... So we have situations that don't appear in ordinary English writing. But this is not a big problem; we just need to remember a general rule: add spaces on both sides of symbols.

Do you feel the code above looks a bit strange? I have to admit it looks a little uncomfortable, but I believe that's just because I'm not used to it yet.

Although not yet accustomed to it, I am sure this code is easier to read and understand.

I can say clearly that if all code followed such conventions, we programmers would find reading code much easier.

Conclusion

I hope no programmer would think that following a predefined coding standard makes programming more difficult!

First of all, all IDEs can be configured to automatically adjust code formatting. You can write code messily, but in the end don't forget to use the IDE's shortcut keys to tidy up the code before committing it. Similarly, I doubt any writer would think that the formatting rules for writing text are too strict and restrict his creativity.

Fortunately, I find that there are no major problems with the use of spaces in all current coding styles and standards. But using a bit more space will definitely make code clearer and easier to read.

Original text:Give your code some space!

Source:Foreign IT Review