Як дотримуватися кращої практики обмеження кількості 80 символів під час написання вихідного коду?


15

Отже, як ви знаєте, є найкраща практика приказки

Обмежте рядок вихідного коду до 80 символів.

Ось 2 посилання:

Чому 80 символів є "стандартним" обмеженням для ширини коду?

Чи обмеження 80 символів все ще актуальне під час широкоекранних моніторів?

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

Але мені це надзвичайно важко, ось приклад прикладу:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference

Отже, ви відступаєте від кожного класу, кожного методу та кожного твердження.

І я вже в стовпці 60 до кінця останнього "e", яке я маю в "myReference".

У мене залишилось 20 пробілів, щоб насправді викликати конструктор і призначити об'єкт посиланням, яке я маю.

Я маю на увазі, чи справді це виглядає краще:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference 
                = new HashMap<String, List<MyInterfaceHere>>(); 

Яка тут найкраща практика?


6
Ми робимо це 140. 80 може бути гарним у дні менших екранів та менших принтерів
tgkprog

7
найкраща практика , якщо ви не на End-Of-Life версій , як 5/6 , ймовірно , буде final Map<String, List<MyInterfaceHere>> myReference = new HashMap<>();(80 символів з відступом , як у вашому прикладі)
комар

4
Мета-найкраща практика - це не сліпо використовувати найкращі практики з двадцяти років тому. Повернувшись, коли 17-дюймовий ЕЛТ підтримував роздільну здатність 1280х1024, нижня межа символів мала сенс, але не сьогодні.
TMN

2
Зауважте, що однією з переваг використання вузьких стовпців тексту, а не розповсюдження по всьому наявному простору на дисплеї є можливість легко переглядати кілька фрагментів коду поруч. 80 chars * 7 pixels/char = 560 pixels per file. Це дозволяє двом файлам (1120 px) зручно розміщуватися на екрані 1280 px або трьох (1680 px) на екрані 1920 px, в обох випадках залишається додатковий простір для номерів рядків, смуг прокрутки, сигілів та інших елементів інтерфейсу користувача . Або навіть випадкові трохи довші лінії.
8bittree

3
@ 8bittree Я можу переглянути код поруч - на двох моніторах. Розвиватися на одному моніторі - це як керувати автомобілем лише з одним колесом.

Відповіді:


18

Найкращою практикою має бути "обмежте довжину лінії, щоб ви, всі ваші колеги та всі інструменти, якими ви користуєтесь, були задоволені нею", а також певний здоровий глузд. 80 символів, здається, дуже низькі і прагнуть зменшити читабельність. Мене колись зовсім обдурила така лінія:

/* Very long comment to the end of the line */ realCode ();

де виклик функції не було видно на екрані (а також не було видно на екрані жодного колеги) без вказівки.

Я встановив моєму редактору відображення поля з 100 стовпцями плюс перемотування коду на дисплеї, тому все завжди видно під час редагування, а занадто довгі рядки, як правило, розбиваються вручну на два, а іноді й більше рядків. Моліться, щоб ваш редактор добре форматував розділені заяви, якщо він робить автоматичне форматування. Використовуйте стиль кодування, який не призводить до глибоко вкладених висловлювань. (Деякі люди створюють гніздо з двадцяти if-висловлювань, за яким йде хвіст із двадцяти інших, що призводить до відступу в 200 символів, і ніхто не може зрозуміти, хто ще належить до якого, якщо).

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

PS. Я зіткнувся з рядками, в реальному написаному людиною коді, що налічував понад 400 символів. Іншими словами, вам доведеться прокручувати віки, щоб прочитати решту рядка, навіть на 24-дюймовому моніторі. Мене не розвеселили :-(


10
Здається, що /* Very long comment to the end of the line */ realCode ();вже слід порушувати деякі інші стильові правила.
Роберт Харві

3
/* Very long comment to the end of the line */ realCode ();є однією з причин, чому IDE мають формати коду, які автоматично ставлять коментар та код в окремі рядки.

2
Він походить із того самого джерела, яке ганебно написало "if (умова) \ n \ tgoto exit; \ n \ tgoto exit;". Лише на кілька років раніше.
gnasher729

Я вважаю, що встановлення максимальної довжини рядка до 80 символів змушує мене думати з точки зору функцій та класів та ОО, замість того, щоб писати довгий рядок тексту, щоб робити все за один кадр. Це змушує мене писати програми, які інші легко можуть підготувати. По-друге, більшість програмістів (на моєму досвіді) я бачив, як у SV працюють на своїх ноутбуках, і у них постійно є великі екранні екрани. Тож написання в обмеженнях розміру 80 символів допомагає всім. По-третє, ви можете розділити великий екран монітора на кілька панелей і переглянути код одночасно.
alpha_989

3

Так, це виглядає краще. Ось чому "Не використовуйте довгі лінії!" Максим такий дуже сильний.

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

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> yReference = newMap();

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


2

Якщо ви застосовуєте довжину / ширину рядка коду, використовуйте інструмент.

  • Resharper
  • Visual Assist
  • тощо.

Розробники вирішують, яка розумна довжина (80, 120, 200 тощо), встановлюють цю опцію в інструменті.

Після цього просто напишіть код так, як зазвичай, без огляду на те, яка ширина чи довга лінія. Після того, як вона буде функціональною і закінчена, клацніть правою кнопкою миші та виберіть « Очистити код» або подібний варіант. Інструмент буде форматувати код, як ви йому сказали, і розбивати довгі рядки, як зазначено.

Бездумно і просто, і кожен вихідний файл буде відформатований однаково.


1

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

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


1

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

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

Зроблено правильно, акуратно розбита лінія набагато легше читається, ніж та, яка зникає збоку екрана.


0

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

/ * Дуже довгий коментар до кінця рядка * / realCode ();

може бути в межах 80 ч, але створює плутанину, оскільки зауваження та параметри коду знаходяться в одному рядку

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.