Я часто чую ці дві цінні практики програмування: (1) рядки коду повинні містити 80 символів або менше і (2) використовувати описові назви змінних, методів, класів тощо. Я розумію міркування обох цих порад. , вони, здається, часто є компромісами один одного. Якщо я тримаю свій код нижче 80 символів / рядка, я в кінцевому підсумку використовую менш описові імена (наприклад, на Python, де кожен відступ рахується як 4 символи), але якщо я використовую більш описові імена, я закінчую рядки, що перевищують 80 символів.

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

Зробіть кілька відступів, ваші імена описовими, і не бійтеся порушити рядок.

Зберігайте відступи кілька.

Часто, коли я опиняюся в боротьбі між відступами та описовим називанням, я роблю крок назад і дивлюсь на свій рівень відступу. Якщо ви відступаєте більше 3-х або 4-х рівнів (2 рівня є автоматичними та неминучими у багатьох випадках. Читайте: визначення методу класу), можливо, ви захочете реструктурувати свій код, віднісши функціональність до функції чи методу.

Ваші імена описові

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

Не бійтеся перервати лінію

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

Чому не обидва?

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

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

Межа в 80 символів, спочатку наслідок технічних обмежень текстових терміналів 1970-х, сьогодні багато хто цінується, і хоча існують технічні причини (максимальна довжина рядків у деяких мережевих протоколах, особливо це стосується електронної пошти), тим переконливіші причини - психологічні та соціальні. Виявляється, довжина рядків навколо позначки 66 символів забезпечує найбільш комфортне враження від читання для природничої мови (розмір шрифту цікаво не має великої різниці, а отже, і розмір екрана чи паперу); Межі рядків на 80 символів досить близькі до цього, але оскільки основна частина типового фрагмента коду зазвичай з відступом принаймні один або два рівні (це означає від 4 до 16 символів, залежно від параметрів відступу),

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

• Функції з довгим списком аргументів; це не є приємною річчю, оскільки вони унеможливлюють читабельність і можуть легко викликати непомітні помилки, наприклад, коли люди міняють порядок аргументів таким чином, що компілятор не вловлює.
• Складні вирази, які часто зустрічаються в умовних (наприклад if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); це теж зазвичай досить важко розшифрувати, і код слід переписати на щось більш структуроване. Швидше за все, вираз робить занадто багато і його слід враховувати у спосіб чи функцію.
• Довгі літерали, що використовуються у викликах функцій або виразах, наприклад print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Перемістіть літерал у змінну чи константу; вона може все-таки перевищувати довжину рядка, але якщо ви будете робити це послідовно, читач може принаймні безпечно ігнорувати невидиму частину рядка, припускаючи, що випливає лише решта літералу. Або ще краще, перемістіть літерали з коду та у зовнішній сховище даних (файл, база даних, що завгодно).
• Глибоко вкладені висловлювання, наприклад, шість рівнів ifвисловлювань методом класу (це 32 стовпчики відступу для типових параметрів). Знову ж таки, глибоке гніздування створює складний і важко читається код, і його слід уникати, як чума - просто кажучи, глибоке гніздування переповнює стек мозку людини під час читання.

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

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

80 символів у рядку не складно зустріти, навіть іменування довгі, тому що існує багато способів розбити один рядок довгого коду на кілька коротких кодів, наприклад, я можу розбити заяву про умову на C на кілька рядків, щоб вмістити менше 40 символи,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

Ви також можете розділити лінію виклику функцій на кілька ліній.

Тому обидва правила описового іменування та 80 символьних рядків не суперечать, вони можуть співіснувати для поліпшення читабельності.

Межа 80 - це те, що мало би давно збільшено. Зауважте, що цей ліміт використовується з віку, коли довжина кожного ідентифікатора була обмежена 8 символами та лише одним шрифтом на екрані / принтері. Немає можливості зміни розміру шрифту.

Боже, у нас зараз різні технології екранування та друку. У нас дуже різні мови програмування. Більше немає причин використовувати 80 символів. Збільшити його принаймні до 120 знаків.

Навіть тоді це не повинно бути жорстким обмеженням. Ви переходите один символ за лінію? Ну, нічого не буває!

Редагувати:

Детальні відповіді про історію 80-лімітного ліміту

Символи на рядок у Вікіпедії

Дослідження в Державному університеті Вічіта показало, що CPL має лише невеликий вплив на читабельність, включаючи фактори швидкості та розуміння. Коли запитували про переваги, 60% респондентів вказали на перевагу або за найкоротші (35 CPL) або найдовші (95 CPL) рядки, які використовувались у дослідженні. У той же час 100% респондентів обрали будь-яку з цих кількостей як найменш бажану.