Блог

Я не уверен, куда мне следует добавить новые пустые строки в моем исходном коде. Я хотел бы написать красивый код, который легко читать и понимать.

Это основано только на объекте или на концепции? Ответы с примерами были бы для меня наиболее полезными.

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

• Единственная пустая строка между функциями, не являющимися членами (и, в C , между функциями-членами, определенными вне класса)
• Одна пустая строка между классами.
• Одна пустая строка до и после комментариев, которые относятся к нескольким последующим функциям / классам, т. Е. которые определяют «разделы» в коде: «вспомогательные функции для обработки XML», такого рода комментарии.
• Нет пустой строки между функциями-членами в классе
• Обычно внутри функции нет пустых строк. Если функция выполняется в несколько этапов, я мог бы поместить пустые строки между ними или просто комментарий между ними, объясняющий этапы. Таким образом, очень длинные функции с большей вероятностью будут разделены пробелами, не то чтобы я считал очень длинные функции особенно хорошей вещью. Если функция-член имеет внутренние пустые строки, я обычно отделяю ее от других функций-членов в классе, которые также содержат пустые строки.

Две последовательные пустые строки кажутся мне немного подозрительными, и я редко когда делаю это сам. Three просто тратит впустую отличное место на моем мониторе — любой, кто хочет, чтобы отдельные вещи, должен IMO поместить их в разные файлы.

Блоки комментариев для автоматической документации (Javadoc, Doxygen, Pydoc и т.п.) Также обеспечивают визуальное разделение — в большей степени, чем несколько строк пробелов, и более продуктивно, чем любое количество пробелов.

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

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

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

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

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

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

Пустые строки до и после комментариев, которые состоят более чем из одной строки.

Каждый класс получает по крайней мере две пустые строки до и после.

Функции разделяются одной строкой.

Другие пустые строки необязательны. Дело в том, что мне нравится, когда комментарии и классы выделяются. Обычно правильное отступление позаботится о большинстве других потребностей. Хитрость здесь в том, чтобы никогда не тратить пространство по вертикали без необходимости.

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

Вероятно, это вопрос предпочтений или стиля работы.

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

стандарты кода для меня — это:

• После окончания каждого оператора if / else (последнего } )
• После каждого метода
• После каждого свойства состоит из нескольких строк
• После сбора поля

пример:

     string a = "Note: ", b= "This", c= "A", d= "String", e= "Test";
    int f=1, h=1;

    string A { Get; Set; }
    string B { Get; Set; }
    string C { Get; Set; }

    string D 
    { 
        Get 
        {
            Return this.d; 
        }
        Set 
        { 
            if (value == "Foo")
            {
               // DoSomething
            } 

            this.d=value; 
        }
    }
    //empty line
  

Ознакомьтесь с макетом исходного кода в StyleCop:http://stylecop.codeplex.com /.
Я бы также рекомендовал FxCop или ReSharper.
Кроме того, Control K the D макетирует документ, но не сортирует пустые строки?

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

то есть рассмотрим этот упрощенный фрагмент php:

 function doStuff(){
    $a = new A();
    $result = $a->foo();

    $b = new B();
    $result  = $b->bar();

    return $resu<
}
  

Было бы лучше, на мой взгляд, поскольку:

 function doStuff(){
    $result = $this->processA();
    $result  = $this->processB();
    return $resu<
}
  

Таким образом, вы по-прежнему улучшаете читаемость, не тратя место в своих файлах.

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