"// ..." коментарі в кінці блоку коду після} - добре чи погано? [зачинено]


18

Я часто бачив, як використовуються такі коментарі:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

а іноді навіть наскільки це можливо

if (condition) {
   ...
} // if (condition)

Я ніколи не розумів цієї практики і, отже, ніколи не застосовував її. Якщо ваш код настільки довгий, що вам потрібно знати, що таке закінчення }, можливо, вам слід розглянути питання про його поділ на окремі функції. Крім того, більшість інструментів розробників здатні перейти на відповідну дужку. І нарешті, останнє - явне порушення принципу DRY; якщо ви зміните умову, вам доведеться пам’ятати, щоб змінити коментар (інакше це може заплутатися для обслуговуючого персоналу або навіть для вас).

То чому люди використовують це? Чи повинні ми його використовувати, чи це погана практика?


У PHP я використовую альтернативний синтаксис для структур управлінняif(condition): ... else: ... endif;
системович

@ Джеффрі ван Вік - справді? Я ніколи не бачив, щоб хтось використовував їх поза файлами шаблонів. Вони надзвичайно нестандартні, але, мабуть, до кожного своє.
Craige

4
@Craige: Будь-яка мовна конструкція, що підтримується PHP, не є "Надзвичайно нестандартною" - інтерпретатор PHP визначає, що таке "стандарт".
Біллі ONeal

Ада має специфічні маркера для кінця більшості конструкцій: if ... then ... end if; while ... loop ... end loop; procedure Foo is ... end Foo;. Я вважаю, що це допомагає розбірливості (і це перевіряє компілятор, котрий коментарі ні).
Кіт Томпсон

Відповіді:


32

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

Однак для мов шаблонів (наприклад, PHP) це може бути дійсним, тому що у вас може бути великий блок HTML, який розділяє початок і кінець умови або структури циклу.


5
Цілком допустима точка для PHP, якщо ви використовуєте PHP, змішаний з Html. 1 бал за Гриффіндора.

3
Навіть із PHP як мовою шаблонів, змішаною з HTML, ви все одно можете відступити. Ви також не повинні використовувати дужки під час використання PHP як мови шаблонів, а, скоріше, while(): endwhile;і foreach(): endforeach;конструкцій тощо.
Htbaa,

9
Я насправді не розумію, чому вам не слід переробляти PHP. Можливо, іншою мовою.
Том Хотін - тайклін

@Htbaa: Я не можу повірити, що я використовував PHP весь цей час і не знав про них. Спасибі! Щодо відступів, я вважаю за краще тримати умовний HTML з відступом таким же, як і на іншій сторінці, а не відповідно до PHP, який його створює.
Метт Еллен

3
@Tom: Я сміявся, але відчуваю свою провину. : P

17

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


15

Це жахлива практика, застаріла багатьма факторами.

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

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

Дуже пропоную проти використання цього.


4
У мене є колега (розробник Java), який це робить. За винятком замість // для та // якщо він використовує // rof та // fi. Це зводить мене з розуму, і він робить це скрізь.
Джей

Так, я мав на цьому наполягати. AAAAAGHHHHH.
Rig

2
Це дійсно не має нічого спільного з програмістами Java або Java, і це не є звичайною або фактично стандартною справою, що потрібно робити при програмуванні на Java.
Джеспер

1
+1,000 за "це жахлива практика".
сканліфф

6

Код читається в 10 разів більше, ніж написано.

Якщо це полегшує читання, зробіть це.

Я також пропоную всім, хто робить це, щоб вони подивилися на деякі інші способи, щоб полегшити читання. Техніки рефакторингу, дужки на різних лініях тощо, про які згадували інші люди, - це все добре. Розділення речей на різні функції, методи або класи, щоб код коментував самоконтроль, також добре. Існують також способи усунення більшості циклів "ifs" та розміщення циклів "for" у очевидних місцях, тим самим усуваючи необхідність у будь-якому з цього.

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


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

@trinithis Що робити, якщо у вас є оператор 20-корпусного перемикача? Іноді вам потрібно підтримати 20 різних варіантів, і краще їх зібрати в одному місці, ніж «переробити» в якусь багаторівневу схему прийняття рішень.
Quant_dev

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

1
@trinithis Йдеться не про те, погано це чи ні, а про ефективні способи допомогти людям оздоровитись, щоб вони зростали через це. Бути ефективним> бути правильним. Це також ідеально розумне зробити, якщо, скажімо, ви переробляєте застарілий код, який ще більше заплутався. Іноді погані речі можуть зробити кращі проміжні кроки і призвести до чогось ще кращого.
Lunivore

1
@trinithis Вибачте, я не можу зрозуміти, що ти маєш на увазі, коли це все в одному рядку. Я думаю, що я згадував, що існують також інші способи рефакторингу коду, яким розробники могли це навчитися.
Lunivore

4

У мене є велика база коду (C ++), наповнена подібними речами:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

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


Гм, я думаю, я не отримую деякого форматування на цьому сайті; кожна дужка вгору повинна бути за своєю лінією, як і орган методу.
ПСУ

У C ++, хоча я часто відкриватиму анонімну область імен у верхній частині для прихованих речей. Тоді в якийсь момент я закриваю цей брекет, і корисно знати, що означає "близький брекет" тут.
CashCow

4

У C ++ є два перехоплення, де це все ще корисно, і поради щодо "розбиття коду" не потрібні:

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

  2. Для пар #ifdef / #endif. Іноді існує багато коду для умовної компіляції, він може стати неприємним при вкладенні, і редактор, який ми використовуємо, часто важко "корисно" усуває відступи, тому коментарі корисні під час швидкого огляду.


+1 для коментаря в просторі імен та причин. Це єдиний раз, коли я роблю це і з тієї ж причини
JohnB

+ тривалі заяви про перемикання.
Quant_dev

1

Для мене код повинен бути заплутаним, щоб додати коментар, як той, який ви вказали.

Якщо це просто сказано // Заява IF. Тоді вам належить замислитися, чому це в першу чергу.


Я згоден, це виглядає як коментований рядок, а не стара школа//endif
StuperUser

1

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

Цей коментар корисний тоді, коли його, як правило, важко простежити, оскільки відкрите сталося давно. Зазвичай це має відбуватися лише для простору імен (зокрема, анонімного в C ++, який використовується для деталізації реалізації в блоці компіляції). У більшості інших випадків повинно бути очевидно, що ви закриваєте.


1

Це значною мірою затримка від старих часів роботи в термінальних вікнах 80x24 символів, особливо якщо ви використовували віконний редактор типу EVE. Навіть зараз я більшу частину своєї роботи виконую в термінальному сеансі за допомогою vim, і я можу розділити сеанс на три або чотири підвікна, тому я можу реально переглядати лише кілька рядків у будь-який час.

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


0

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


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

Можливо, він був використаний у якомусь підручнику, тому купу людей вийшли з коледжу, використовуючи його? Це може мати місце у вступному тексті. Також обгрунтовано дійсний у препроцесорі, особливо в # ifdef / endif включають охоронців
Мартін Бекетт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.