Недавно в нескольких разных командах я обнаружил, что их стандарты кодирования сильно различаются в использовании пробелов. Это вызвало моё любопытство, потому что я всегда считал, что должно существовать общепризнанное лучшее правило использования пробелов при форматировании кода. Но в реальной разработке такого единообразия, похоже, так и не возникло.

Текущее состояние

Сначала давайте посмотрим на соглашения о стиле для кода Java в большинстве Java IDE.

Вот пример:

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
    }
}

Обратите внимание, что это самый распространённый стиль среди Java-программистов и в других C-подобных языках.

Внутри круглых скобок нет пробелов ни слева, ни справа. Только когда перед круглой скобкой стоит ключевое слово, такое как 'for' или 'while', между ними появляется пробел, но между именем метода и следующей за ним круглой скобкой пробела нет. Однако перед открывающей фигурной скобкой (которая обычно появляется в конце строки) всегда есть пробел. Математические операторы всегда окружены пробелами. А перед точкой с запятой пробела нет.

Если вы часто читаете код, вам это расположение может показаться вполне естественным, но если вы не программист, эти правила могут показаться вам слишком произвольными, со множеством несоответствий, особых случаев и спорных моментов.

Пожалуйста, оставляйте больше места для своего кода

В моём текущем проекте разработки в компании есть две основные команды разработчиков: одна — команда Load Test Products (LTP), а другая — команда Functional Test Products (FTP). Обе команды следуют определённым соглашениям о стиле кодирования, и обе особенно щедры на пробелы, как в следующем примере фрагмента кода:

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
    }

}

Этот стиль делает код менее плотным и более единообразным (например, перед открывающими круглыми скобками пробела нет, а внутри всех круглых скобок, фигурных скобок и квадратных скобок есть пробелы слева и справа)! Я не говорю, что это лучше или хуже предыдущего стиля... он просто облегчает различение слов. Плата за это — на одном экране помещается меньше кода.

Хотя у каждого стиля кодирования есть свои преимущества и недостатки, меня удивило то, что команда разработчиков FTP в конце концов решила перейти к самому распространённому стилю кодирования, упомянутому ранее. Они считали, что это изменение оправдано, и они даже обсуждали его, так что, я полагаю, они считали это изменение важным. Их решение основывалось не на том, лучше ли этот стиль того... Я думаю, в основном оно было сосредоточено на том, кто привык к этому стилю, поскольку большинство наших продуктов имеют открытый исходный код, что является важной причиной: это облегчает программистам из сообщества вклад в код.

В моей команде, команде LTP, мы по-прежнему придерживаемся нашего стиля и не намерены вносить какие-либо изменения. По крайней мере для меня это решение, основанное на технических соображениях: если другой стиль кодирования не показывает никаких преимуществ (нашему проекту почти не нужны вклады с открытым исходным кодом), зачем переходить на другой стиль?

Правила должны быть едиными

Я вносил код в проекты с открытым исходным кодом, например в язык программирования Ceylon, и был очень удивлён, что они вообще не придерживались никакого стиля кодирования. Вы можете писать код в любом стиле, который вам нравится.

Некоторым программистам, которых отпугнул огромный объём стандартов кодирования в некоторых компаниях, это может понравиться, но я считаю, что без набора стандартов кодирования код вашего проекта, скорее всего, погрузится в хаос форматирования. Каждый участник, вносящий код, при отправке кода привносит свой собственный уникальный стиль кодирования, что неудивительно; в результате весь код разнороден, и вы можете увидеть несколько разных стилей в нескольких строках кода ниже:

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);

Основной вопрос, который я хочу поднять: действительно ли стиль кодирования является важной практикой разработки? Насколько он влияет на эффективность программистов при разработке программного обеспечения?

Я считаю, что этот вопрос связан с другим похожим вопросом: влияет ли форматирование кода на читаемость кода?

Форматирование кода влияет на читаемость кода

Я думаю, на этот вопрос очень легко ответить! Конечно, да. Визуально просмотрите следующие два фрагмента кода строка за строкой (взято из проекта Ceylon), и вы легко почувствуете, какой из них легче читать. – 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;
}

Разница может быть небольшой, но если вы целыми днями тратите много времени на чтение большого количества кода, разница становится огромной.

Уроки, извлечённые из обычного написания текстов

Когда речь заходит о читаемости кода, возможно, нам стоит взглянуть на более обычную способность людей читать текст. Эта способность развивалась на протяжении тысяч лет, так что лучшее решение уже должно было быть найдено!?

В «обычном» английском вы можете увидеть традиционное использование пробелов, но вы не увидите, чтобы писатели обсуждали, нужно ли ставить пробелы вокруг скобок! Так как же это выглядело бы, если бы код писали как «обычный» английский?

Давайте вернёмся к простому примеру выше:

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;
}

Большинство вещей в коде совпадают с обычными английскими предложениями. Вы используете скобки, чтобы «сгруппировать» определённые слова. Вы используете пробелы между словами и символами — здесь мы находим место, отличающееся от обычных привычек в программировании: когда мы вызываем метод, между именем метода и следующими за ним скобками нет пробела, и после оператора точки пробел не оставляется.

Я могу понять, почему в этих местах нет пробелов, потому что эти скобки или точки в коде представляют своего рода «принадлежность» или связь. Но действительно ли необходимо экономить этот кусочек места, чтобы обозначить эту связь? Разве пример кода выше не кажется очень ясным?

Ещё одна вещь, которой нет в обычном английском, — это вложенные выражения... Так что у нас есть ситуации, которые не встречаются в обычном английском письме. Но это не большая проблема; нам просто нужно помнить общее правило: добавлять пробелы с обеих сторон символов.

Вам кажется, что код выше выглядит немного странно? Должен признаться, он выглядит немного непривычно, но я полагаю, что это просто потому, что я ещё к нему не привык.

Хотя я ещё не привык к этому, я уверен, что этот код легче читать и понимать.

Могу сказать определённо: если бы весь код следовал таким соглашениям, нам, программистам, было бы гораздо легче читать код.

Заключение

Надеюсь, ни один программист не подумает, что следование предопределённому стандарту кодирования делает программирование более трудным!

Прежде всего, все IDE можно настроить на автоматическое форматирование кода. Вы можете писать код как попало, но в конце не забудьте использовать сочетания клавиш IDE, чтобы привести код в порядок перед коммитом. Точно так же сомневаюсь, что какой-нибудь писатель посчитает правила форматирования текста слишком строгими и ограничивающими его творчество.

К счастью, я обнаружил, что в использовании пробелов во всех текущих стилях и стандартах кодирования нет серьёзных проблем. Но использование чуть большего количества пробелов определённо сделает код яснее и легче для чтения.

Исходный текст:Дайте вашему коду немного пространства!

Источник:Зарубежное ИТ-обозрение