Висловлено кілька зауважень щодо білого простору, коли вже обговорювалося розміщення фігурних дужок.

Я сам схильний посипати свій код порожніми рядками, намагаючись розділити речі, які поєднуються в "логічних" групах, і, сподіваюся, полегшити наступній людині прочитати код, який я тільки що створив.

Насправді я б сказав, що я структурую свій код так, як пишу: я роблю абзаци, не довше ніж кілька рядків (безумовно, коротших за 10), і намагаюся зробити кожен абзац самостійним.

Наприклад:

• у класі я згрупую методи, які йдуть разом, при цьому відокремлюючи їх порожнім рядком від наступної групи.
• якщо мені потрібно написати коментар, я зазвичай ставлю порожній рядок перед коментарем
• в методі я роблю один абзац за крок процесу

Загалом, у мене рідко є більше 4/5 рядків, згрупованих разом, що означає дуже рідкий код.

Я не вважаю весь цей простір марнотратним, тому що фактично використовую його для структури коду (як фактично я використовую відступ), і тому я вважаю, що це варто для екрана.

Наприклад:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

Я вважаю, що обидві заяви мають чіткі чіткі цілі, і тому вони заслуговують на те, щоб бути відокремленими.

Отже, як ви фактично використовуєте (чи ні) порожні рядки в коді?

Завжди

Пробіл має важливе значення для очищення читабельного коду. Порожній рядок (або два) допомагають візуально відокремити логічні блоки коду.

Наприклад, із кодексу Стіва Макконнелла, другого видання, про тему "Макет і стиль":

Піддослідні набрали на 20–30 відсотків більше, ніж тест на розуміння, коли програми мали схему відступу на два-чотири пробіли, ніж у тих, коли програми взагалі не мали відступів.У цьому ж дослідженні було встановлено, що важливо ні підкреслювати, ні надмірно підкреслювати логічну структуру програми. Найнижчі результати розуміння були досягнуті для програм, які зовсім не були відступними. Другий найнижчий показник досягнуто в програмах, які використовували шість пробілів. Дослідження зробило висновок, що відступ від двох до чотирьох просторів є оптимальним. Цікаво, що багато суб’єктів експерименту вважали, що відступ з шести пробілами легше використовувати, ніж менші відступи, хоча їхні бали були нижчими. Це, мабуть, тому, що шість космічних відступів виглядає приємно. Але незалежно від того, наскільки це красиво виглядає, шість пробілів виявляється менш читабельним. Це приклад зіткнення естетичної привабливості та читабельності.

Так, для ясності.

Так само, як я робив у цій відповіді.

Я це роблю, але переконуюсь, що це документую, додаючи

(This line intentionally left blank.)

на лінії

Так, але я не зловживаю цим.

Я бачив код, де кожен рядок коду всередині методу розділений порожнім рядком, а два порожні рядки використовуються там, де відбувається логічне розділення. Це просто робить його ще менш зрозумілим на мій погляд. Я також бачив пробіл, який використовується для здійснення шалених вирівнювань, таких як цей:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

Таке ж неправильне використання горизонтального простору може бути застосовано до вертикального пробілу. Як і будь-який інструмент, використовуйте його розумно.

Мене дуже критикують за те, що я написав свій код таким чином. Я не розумію, чому хтось не зробив би це так.

Читання, що так важливо, коли ви повернетесь до проекту через тривалий проміжок часу, і я почув приказку "Завжди пишіть код, якщо наступний хлопець, який його читає, - це психопат, який знає ваше місце".

Я не завжди пишу програмне забезпечення, але коли я це роблю, я використовую порожні рядки для наочності.

Я все для того, щоб зробити код максимально зрозумілим, і пробіл часто є корисним інструментом для цього. Але не будемо забувати рефакторинг:

• у класі я згрупую методи, які йдуть разом, при цьому відокремлюючи їх порожнім рядком від наступної групи.

Оскільки у вас є кілька пов’язаних членів, вони є кандидатом у новий клас.

• якщо мені потрібно написати коментар, я зазвичай ставлю порожній рядок перед коментарем

Щоразу, коли код недостатньо зрозумілий, щоб хотіти коментар, я запитую, чи зможу я рефактор, щоб зробити код чітким, щоб коментар не потребував.

• в методі я роблю один абзац за крок процесу

Чому б не зробити один метод для кожного "абзацу"?

Якщо ви закінчите купу методів у своєму класі, дивіться мою замітку про вилучення нового класу.

Так. Це полегшує візуальне сканування файлу. Крім усього іншого, стає зрозумілішим, до якого рядка йде коментар.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

Я використовую порожні рядки скупо і послідовно, і послідовно важливіше, ніж щадно. Однак:

• Якщо кожен рядок коду відокремлений від наступного порожнім рядком, занадто багато порожніх рядків.
• Якщо ні рима, ні розум легко помітні, де розміщені порожні рядки, то вони є відволіканням, і їх зазвичай занадто багато.
• Якщо функція настільки велика, що їй потрібно багато порожніх рядків, вона занадто велика.
• Якщо блоку коду потрібно більше одного пустого рядка до нього або після нього, щось серйозно заблукає.
• Якщо між функціями є більше двох порожніх рядків, напевно, у вас занадто багато порожніх рядків.

Більшість із них не є страшно суперечливими; що може бути далі. Зауважу, що позначення K&R з відкритими дужками в кінці рядка гнітюче часто супроводжується порожнім рядком. Мені особисто не подобаються дужки в кінці рядка і змішування цього з порожнім рядком після дужки робить дурниці позначень (IMNSHO). Розмістіть відкриту дужку на наступному рядку самостійно, і у вас здебільшого порожній рядок (і, IMNSHO, більш читабельний код). Якщо вам потрібно скористатися дужкою K&R в кінці рядка, не витрачайте на вертикальне простір економію сторонніми порожніми лініями.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

Напишіть те, що є найбільш розбірливим і найменш дивним.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Для цієї функції не потрібно 12 рядків коментарів док.

Насправді це не потребує жодних коментарів.

Або порожні рядки.

Вони б зашкодили її суті.

Всередині функції? Рідко

Якщо у мене чітко інший блок, він перетворюється на нову функцію. Якщо мало випадків цього не варто.

Для мене пусті рядки всередині функції - одна з найбільш неправильних «найкращих практик».

Часто

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

Хороший пробіл

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Поганий пробіл

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

проти

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

проти

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

Я не тільки використовую пробіли, я використовую брекети для ясності.

Дужки, які я використовую, щоб сказати, це потенційно можуть бути функціями.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

Свого часу я просто розсипав порожні рядки по всьому коду. У наш час я, як правило, більш щадний. Я думаю, що це частина того, про що тут говорив Стів Йегге :

Сподіваємось, сцена, яку я намалював поки що, допомагає вам зрозуміти, чому іноді ви дивитесь на код і просто ненавидите його негайно. Якщо ви n00b, ви подивитесь на досвідчений код і скажете, що це непроникне, недисципліноване лайно, написане кимось, хто ніколи не вивчив основ сучасної інженерії програмного забезпечення. Якщо ви ветеран, ви подивитеся на код n00b і скажете, що це надмірно коментований декоративний пух, який стажер міг записати за одну ніч сильного пиття.

Точкою стикання є толерантність до стиснення. Коли ви пишете код протягом своєї кар'єри, особливо якщо це код, що охоплює дуже різні мови та проблемні домени, толерантність до стиснення коду зростає. Він не відрізняється від прогресування від читання дитячих книг з гігантським текстом до все складніших романів з меншим текстом і більшими словами.

...

Програміст з високою толерантністю до стиснення насправді перешкоджає екранізації розповідей. Чому? Тому що для розуміння кодової бази потрібно вміти запакувати якомога більше її в голову. Якщо це складний алгоритм, ветеран-програміст хоче бачити всю річ на екрані, що означає зменшення кількості порожніх рядків та вбудованих коментарів - особливо коментарів, які просто повторюють, що робить код. Це абсолютно протилежне тому, що хоче програміст n00b. n00bs хочуть зосередити увагу на одному висловлюванні чи виразі одночасно, переміщуючи весь код навколо нього з поля зору, щоб вони могли сконцентруватися і плакати вголос.

Я принципово з ним згоден. Набагато краще стиснути код, щоб ви могли отримати якомога більше його на одному екрані, ніж занадто багато місця. Це не означає, що ніколи не слід використовувати порожні рядки. Я думаю, що тільки якщо угруповання, яке ви намагаєтесь створити, не збільшує читабельності надзвичайно, це приносить більше шкоди, ніж користі.

Професор Емерітус дав дві великі поради

1. Пробіл безкоштовний
2. Не використовуйте скоби, які висуваються назад передньою стороною паперу, інакше я вас зірву.

Мої правила:

1. Якщо у мене є проблеми з читанням коду, про який я написав вчора, мені, мабуть, потрібно витягнути метод або три.

2. Якщо визначення мого класу занадто довге, щоб легко його читати, можливо, мені потрібно витягнути модуль / інтерфейс / об’єкт.

3. Визначення методу: додайте рядок

4. Визначення модуля / класу: додайте два рядки

Мені подобається думати про пробіли так само, як і паразитування. Ви групуєте лінії, що сприяють одній ідеї.

Якщо ви починаєте нову ідею або нову грань тієї самої ідеї, ви починаєте новий абзац - як цей.

В імперативному коді я групую завдання, які виконують одне згуртоване завдання; у декларативному коді я групую код, який описує одне злагоджене висловлення ідеї.

У вас, очевидно, не виникає проблем з англійською мовою (деякі люди жахливі з параграфами), тому, маючи невелику практику, застосовувати той самий навик до коду, це взагалі не повинно бути розтягнутим.

Порожні рядки - це, на мою думку, обов'язково. Я використовую їх для розділення різних логічних блоків коду. Робить код читабельним. Читаний код - хороший код;)

Моїм ідеальним фрагментом коду буде кожен логічний блок, розділений порожнім рядком та коментарем вгорі кожного блоку, який має основну логіку.

Звичайно, якщо люди старші роблять це, додаючи скрізь кілька порожніх рядків, я вважаю це дуже дратівливим :(

Я використовую лише пробіли в межах функції / методу, щоб розділити декларації та код.

Якщо ви відчуваєте необхідність мати кілька рядків для розділення підблоків коду, що реалізує певну логіку, то вони повинні бути, але в іншому функціональному / приватному методі. Ваш компілятор повинен вирішувати не робити надто великих витрат.

як правило, в peusdo-коді:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Якщо я бачу марний пробіл, я зазвичай пригнічуюсь.

Білий простір надзвичайно цінний.

Ось угода ... ботаніки, які пишуть складний код на зразок E = MC ² , чудово демонструють свої навички програмування.

Тепер давайте стрибаємо на півроку, і це 2:00 ранку, і система, яку не дивилися протягом шести місяців, зламалася на самій лінії E = MC ² . Налагодити це майже неможливо ... всі вигадують.

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

See Dick
See Jane
See Dick and Jan

Якщо це 2:00 ранку, і код порушено. Швидкий погляд покаже вам, що третя лінія мала бути

See Dick and Jane

Проблема вирішена.

Підсумок ... використовуйте пробіл.

Як зазначають багато інших, порожні рядки полегшують читання коду. Однак є деякі мови, які застосовують цей стандарт. Я можу придумати верхню частину голови (не стільки про порожні рядки, скільки належне відступ) - це Python.

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

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

Відповідь Психопата - найкраща, але я замінив би її припущенням, що наступна людина - ідіот, і що вони припустять, що ти є, і ти захочеш довести їх неправильно.

Так само важливим для читабельності є використання коментарів. Я відкриваю кожну функцію або підпрограму блоком коментарів, пояснюючи чітким текстом, що це таке, що робить, які аргументи та які очікувані результати (включаючи список умов помилок). Тоді не виникає сумніву, що він призначений та / або призначений робити. Те, чого вона досягає, може бути різною, але це далі вниз.

Я думаю, що занадто багато кодерів або припускають, що саме вони будуть робити "ремонт" коду, або просто не байдуже.

Порожні лінії важливі. Однак витрата цілого порожнього рядка на вступну дужку зменшує кількість коду, який ви можете побачити на екрані. Має бути:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Не запускайте мене починати ставити дужку "{" на тій же лінії, що і "за" ... це мешугга).

Так. Для читабельності. Іноді я навіть кладу порожні рядки в код, який я не писав. Мені легше зрозуміти код, коли у них є логічне групування через порожні рядки - наприклад, ти можеш "швидко читати" через нього.

Ми повинні використовувати порожні рядки між кодовими блоками, як це робимо під час написання листа.

Наприклад, між функціями або всередині функції, коли ми закінчуємо цикл ...

Люди будуть вдячні вам за чистий код, якщо їм доведеться його обслуговувати;)

Ми використовуємо пробіли, рекомендовані Microsoft StyleCop. Крім читабельності та послідовності, я виявив, що (разом з невеликими розмірами класів) правильно складений код полегшує управління об'єднаннями, коли різні люди в команді працюють на одних і тих же ділянках.

Я не впевнений, чи це лише моя фантазія, але різні інструменти здаються кращою роботою для розпізнавання того, де починається і закінчується еквівалентний код при злитті, коли він акуратно викладений. Гарно викладений код - це радість злитися. Гаразд, це була брехня - але принаймні біль тримається до рівня керованості.

Ніколи пустий рядок не у всьому файлі. Це не означає, що в коді немає перерв:

 code;
 //
 morecode;

Пусті рядки призначені для відкриття розділів коду для роботи, у вашому редакторі є кілька гарячих клавіш, щоб перейти до попереднього / наступного порожнього рядка.