Наскільки важливо зменшити кількість рядків у коді?

Я розробник програмного забезпечення, який працює на J2SE (core java).
Часто під час огляду коду нас просять зменшити кількість рядків у нашому коді.

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

Як ви вважаєте, що це правильний спосіб робити речі?
Якщо LOC (рядки коду) - це невелика кількість, як це впливає на код? Якщо LOC - це більша кількість, як це впливає на код?

приклад з веб-сайту: "javaranch" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

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

Вимірювання SLOC (що ефективно робить ваші відгуки) робить SLOC важливим .... Чи важливий SLOC? - абсолютно ні, ніколи не був (За конкурсом програмування поза межами прихованого ), ніколи не буде в комерційній організації.

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

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

Ось зірочка, хоча. Йдеться не про фактичну кількість рядків коду в ідеї, оскільки ви можете зменшити кількість рядків на щось подібне:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

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

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

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

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

Як колись сказав Кен Томпсон: Одним з моїх найпродуктивніших днів було викидання 1000 рядків коду .

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

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

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

В даний час я працюю старшим розробником програм та бізнес-аналітиком для великої компанії, і ніколи не вважав, що число моїх розробок було центром інтересу. Однак я вважаю, що чим більше може бути згущений код, тим краще, АЛЕ не ціною того, що можна швидко проаналізувати та виправити (або додати до нього). Для мене, коли ви відповідаєте за найважливіший бізнес-додаток, що ОБОВ'ЯЗКОВО має бути величезним рівнем масштабованості та здатним до літ зміни в умовах безперервного зміни, лаконічний, легкий для читання код - один з найважливіших елементів розвитку . На честь відповіді Еріка Дітріха це:

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

було б для мене абсолютно неприйнятним, однак я виявив, що змінює всі існуючі компанії компанії код:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

до:

value.prop =  boolean ? option1 : option2;

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

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

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

На мій досвід, ефективний код:

• не порушує жодного із принципів SOLID
• є читабельним і зрозумілим
• проходить тест Альберта Ейнштейна на простоту: "Все повинно бути зроблено максимально просто, але не простіше".

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

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

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

Очевидними є переваги низьких показників LOC (малі методи вкладаються у вашу голову легше, ніж великі; менше речей у коді означає, що менше помиляється тощо), але це також підпадає під дію закону зменшення прибутку. Перестроювання методу 150 ліній на декілька 20 лінійних методів - набагато більший виграш, ніж рефакторинг методу з 10 ліній на метод 7 рядків.

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

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

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

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

На жаль, люди можуть бути нераціональними, особливо якщо мова йде про людей, які нижчі за пекельний порядок, що ставить під сумнів свої рішення та правила, які вони вам нав'язали. Вони можуть вирішити не бути розумними. До цього теж потрібно бути готовим. Якщо ви можете продемонструвати випадки, коли найкраща практика LOC вступає в прямий конфлікт з іншими найкращими практиками, і чому це шкодить продукту, і якщо ви можете це робити в частині бази коду, для якої вони мали незначну участь або не мали жодної участі (так це не Це не здається особистою атакою на їх роботу або роботу, яку вони контролювали), то це може допомогти посилити ваш аргумент. Знову ж таки, ви повинні бути готові виправдовувати себе спокійно, раціонально і мати можливість «володіти» аргументами, які ви висуваєте.

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

Я думаю, ви дійсно повинні прагнути мати функції з невеликою кількістю SLOC.

Якщо LOC (рядки коду) - це невелика кількість, як він впливає на код і якщо LOC - це більша кількість, як він впливає на код?

В ідеалі слід простіше зрозуміти 8 рядків коду з першого погляду, ніж слід зрозуміти 30.

Це не означає, що 30 LOC, стиснених у 8 рядках, буде легше зрозуміти.

Як ви вважаєте, що це правильний спосіб робити справи.

Зазвичай у функції я намагаюся групувати її за рівнями абстракції ("тут код IO", "тут валідація", "тут обчислення" тощо).

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

Це означає, що у мене були зроблені функції з цим вилученням, і після нього функція становила ~ 40 рядків (код C). Якщо код максимально згрупований, я не бачу проблем із довшими функціями.

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

булева sweet_sixteen = (вік == 16);

є досить зайвим. Хто це читає "вік == 16" це знає. Я б скоріше написав такий код:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

Логіка вирішення питання, коли вигнати партію, є окремою від System.out, може бути перевірена, і це легко зрозуміти. Що ще важливіше, хоча хтось, читаючи код, може зрозуміти причину, коли його написали саме так («компанія хоче організувати велику вечірку для когось із людей»).

Я думаю, що менше рядків коду = більше читабельного коду

Але звичайно, є певна межа, коли ви починаєте мінімізувати / затемняти свій код лише для отримання меншої кількості рядків.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

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

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

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

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

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

Ваш приклад вказує на випадок, коли більша кількість рядків коду має сенс. Але це той приклад. Щодня я бачу приклади, коли кількість рядків прив’язана до недостатнього планування

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

Це також може вплинути на дизайн та вибір мови: зменшення функціональних точок або перехід на мову з нижчим LOC / FP повинно зменшити зусилля проекту, а всі інші рівні.

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

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

Загалом, корисно додавати абстракції у свій код та використовувати помічники тощо, але знову ж таки, ці абстракції можуть стати занадто численними. Що також може статися, це перенести складність на іншу частину коду. Іноді, наприклад, коли ви як експерт проектуєте рамку / бібліотеку для використання молодшими програмістами (або студентами), це добре зробити. Але не сподівайтеся, що юніори зможуть зрозуміти, як працює ваш код, просто змусьте їх неправильно використовувати його.

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

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

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

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

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

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

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

Якщо для виконання вашого завдання потрібно 10 рядків коду, так і бути, ви робите це в 10 рядках. Якщо для цього потрібно 10 000 рядків, тож саме так і буде, ви робите це в 10000 рядків. Культ "меншої кількості рядків коду" не зробить останній приклад кращим, якщо ви будете робити це в 1000 або 2000 або ще. Для роботи потрібно 10 000 рядків, і ці 10 000 рядків можуть включати шари перевірки, перевірку помилок, безпеку тощо, які будуть пропущені, якщо ви зробили їх у меншій кількості.

Редагувати

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

Тепер розглянемо наступне:

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

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

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

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

Отже, що гарантує менше рядків коду? Менше рядків коду, це все.

Глибоко неправильно зосереджуватись на тому, щоб виконувати ту саму роботу в 2000 рядках проти 10 000. Натомість зосередьтеся на коді, який працює, який є надійним, який працює в межах прийнятих допусків, і його легше читати і продовжувати рухатися вперед. Іноді це означає, що ви можете зробити це в низькому розмірі LoC, іноді це означає, що ви повинні зробити це у більшій кількості LoC, але кількість LoC не повинна бути важливою.

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

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

1. Складіть блок-схему своєї проблеми
2. Спробуйте використовувати меншу кількість петель, як тільки можете
3. Викликів функцій не повинно бути багато
4. Нові структури даних, такі як TRIE, слід використовувати в тому випадку, коли стек або черга використовується для зберігання відповідної інформації.
5. І намагайтеся вирішити проблему реалістичним підходом, а не творчим, коли ви зберігаєте величезну кількість чисел у дуже великому масиві, а потім намагаєтесь отримати доступ до нього через масив.]
6. Використовуйте якомога більше макросів. Далі підхід до використання також залежить від проблеми. Якщо вона дійсно складна, то іноді використання простого підходу також еквівалентно складному