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

Я разработчик программного обеспечения, который работает на J2SE (ядро Java).
Часто во время наших обзоров кода нас просят уменьшить количество строк в нашем коде.

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

Как вы думаете, как правильно делать вещи?
Если LOC (строки кода) небольшое число, как это влияет на код? Если LOC больше, как это влияет на код?

Пример с сайта: "Джаваранч" -

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.");
    }
}

В.С.

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);

довольно избыточно. Любой, кто читает "age == 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 строк, то так и будет, вы делаете это в 10 000 строк. Культ «меньшего количества строк кода» не улучшит последний пример, если вы сделаете это за 1000, 2000 или что-то еще. Для выполнения задания требовалось 10000 строк, и эти 10000 строк могут включать в себя уровни проверки, проверки ошибок, безопасности и т. Д., Которые будут пропущены, если вы сделаете это за меньшее количество времени.

редактировать

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

Теперь рассмотрим следующее:

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

• Если строка кода выполняет API-вызов (или другой вызов во внешнюю библиотеку), то у вас по определению практически нет прямого контроля над тем, что выполняется, и насколько это эффективно.

• Проверка ошибок, очистки и т.д. все добавить дополнительные строки кода , и я совершенно уверен , что даже самый ярый поклонник меньше строк кода не будет возражать против тех .

Итак, строки кода - это ломаная метрика. Меньшее количество строк кода не гарантирует дополнительную производительность - этот вызов API или библиотеки является одной строкой и может находиться вне вашего контроля. Меньшее количество строк кода не гарантирует дополнительную надежность - проверка ошибок и очистка всегда потребуют дополнительных строк. Меньшее количество строк кода даже не гарантирует дополнительной читаемости или удобства сопровождения - вам нужно только взглянуть на IOCCC, чтобы знать это.

Так что же гарантирует меньшее количество строк кода? Меньше строк кода, вот и все.

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

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

В более ранний период предполагалось, что если число строк кода, которое является loc, велико, то код эффективен, и он выполняет все задачи, для которых он используется, но через некоторое время он понял, что чем меньше, тем больше его имеет эффективность, так как затраты, понесенные системой при выполнении кода, очень меньше. Таким образом, для улучшения системы loc должен был быть сделан меньше. Так как тогда предполагалось, что локаль будет меньше. Чтобы уменьшить его, необходимо учитывать следующие факторы должны быть приняты во внимание.

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