Вы действительно пишете «чистый код»? [закрыто]

Я видел, как некоторые программисты перекраивали свой код снова и снова не только для того, чтобы он «работал хорошо», но и чтобы он «хорошо выглядел».

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

Итак, сколько из вас на самом деле пишут «чистый код»? Это хорошая практика? Каковы другие преимущества или недостатки этого?

Я бы сказал, что многие из нас не пишут чистый код . И вообще, это не наша работа . Наша работа как разработчиков программного обеспечения заключается в предоставлении продукта, который работает вовремя.

Мне вспоминается запись в блоге Джоэла Спольски: Программатор магнитофонов .

Он цитирует кодеров на работе :

В конце дня отправьте эту чертову вещь! Здорово переписать ваш код и сделать его чище, а в третий раз он станет действительно красивым. Но дело не в этом - вы здесь не для написания кода; Вы здесь, чтобы отправлять продукты. - Джейми Завински

Мне также напомнили об ответе блога Роберта Мартина :

Так. Быть умным. Быть чистыми. Будь простым Корабль! И держите маленький рулон клейкой ленты наготове, и не бойтесь использовать его. - Дядя Боб

Если код, который пишет разработчик, оказывается чистым И РАБОТАЮЩИМ (доставляемым), пусть будет так, хорошо для всех. Но если разработчик возится с попытками сделать чистый и читаемый код за счет возможности его своевременной доставки, то это плохо. Заставьте это работать, используйте клейкую ленту, и отправьте это. Вы можете изменить его позже и сделать его великолепным и эффективным.

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

Хороший кусок кода, с которым я столкнулся, не чистый. Некоторые совершенно безобразны. Но все они были выпущены и использованы в производстве. Некоторые могут сказать, что писать беспорядочный код непрофессионально. Я не согласен. Профессиональная задача - доставить работающий код, будь то чистый или грязный. Разработчик должен сделать все возможное, учитывая время, выделенное перед доставкой. Затем вернитесь, чтобы навести порядок - это профессионально. Надеюсь, поставленный код не является чистой клейкой лентой и является «достаточно чистым».

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

Но вы говорите over styling(как этот термин лучше, чем код девушки ), который служит только эго своего автора.

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

Это слишком много.

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

Я бы не согласился с принятым ответом на этот вопрос.

Очевидно, что вы несете ответственность за доставку, но обычно вы также несете ответственность за доставку того, что обслуживаемо и как можно более экономически выгодно для вас и будущих разработчиков.

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

Я знаю, что по этому поводу существует статистика, но по моему опыту в нескольких проектах каждая написанная строка кода читается 5-20 раз во время расширения и обслуживания.

Поэтому я бы сказал, чтобы очистить код с точностью до дюйма его жизни . Это требует времени, но, скорее всего, это экономит чистую стоимость в течение всего срока реализации проекта.

Будет ли кто-нибудь из нас покупать автомобиль, если мы знаем, что под капотом все беспорядочно и трудно устранять неисправности, обслуживать или ремонтировать, и для его запуска требуется больше ресурсов, чем нужно?

Почему это должно быть иначе для части программного обеспечения?

То, что конечные пользователи не могут заглянуть под капот, не означает, что они никогда этого не узнают. Рано или поздно это появится.

Отвечая на вопрос «Вы действительно пишете« чистый код »?» -- О да.!

Если под «чистым кодом» вы имеете в виду, я стараюсь изо всех сил, чтобы убедиться, что код максимально ясен?

Черт возьми, да.

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

Честно говоря, это зависит. Мне нравится, как все говорят о том, что «что-то меньшее, чем чистый, хорошо документированный код - просто пародия!», Но я работаю в бизнесе со смешными циклами развертывания и нулевым упущением: я делаю все, что могу, но я пишу так большого количества кода чрезвычайно сложно написать чистый совершенный код, который, как утверждают все остальные, они пишут.

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

Иногда я чувствую себя немного виноватым, но не очень. Вы должны увидеть некоторые ужасы, с которыми я сталкиваюсь ежедневно. Десятилетия пользовательского кода на непонятных языках с нулевой документацией. Один из моих коллег разрабатывает исключительно на Visual Basic 6.0 и развертывает зашифрованные двоичные файлы повсюду. Женщина, которую я заменил, запрограммирована исключительно в RPG .

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

Я не думаю, что мне нравится термин "код девушки", но чистый код = поддерживаемый код. Все, что меньше, непрофессионально.

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

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

Я пытаюсь написать «чистый код» в смысле Боба Мартина (например, дизайн ОО). В написании чистого кода есть большая ценность. Это намного более ремонтопригодно.

Затем я позволил ReSharper создать для меня «красивый код» (например, выравнивание, разрывы строк и т. Д.). В написании красивого кода есть хорошая ценность. Но есть и убывающие доходы. Некоторая преттификация делает его немного более удобным из-за удобства чтения.

Если вы чувствуете, что аккуратное выравнивание огромных блоков кода необходимо для того, чтобы сделать его читабельным, тогда проблема в том, что вы чертовски большой блок кода! Это слишком большое. Я вижу много примеров того, как люди прикладывают большие усилия, чтобы претенциозировать какой-то очень плохо разработанный код.

Если бы у меня не было ReSharper, у меня все равно был бы чистый код, но он не был бы таким красивым.

Я не думаю, что я должен тратить более ~ 5% своего времени на программирование на предварительные расчеты. Это значит, что чем сильнее мой редактор и чем я лучше в нем разбираюсь, тем больше претенциозности я могу сделать.

Кажется, никто не поднимает вопрос о том, что в интересах вашей компании?

Часто, если не всегда, программисты являются просто сотрудниками, и, хотя управленческие решения могут нас расстроить, мы часто не имеем всех данных, которые они делают.

Например, скажем, что компания заключила контракт с условием, что если программное обеспечение не будет готово вовремя, вам не заплатят (это просто случилось с нами, хотя я думаю, что мы все-таки получили платеж). Да, чистый код важен, но важнее, чтобы код работал до дня оплаты!

Другой пример - у компании плохое финансовое положение, и ей нужно собрать немного денег. Угадайте, кого волнует качество? Вы можете исправить это позже, если вам нужно, просто отправьте его!

Аргументом может быть «Почему я должен продавать и писать дерьмовый код?». Ну, почему ваша компания должна платить вам хороший чек каждый месяц? Выборы, друг мой. Если вы после идеализма, попробуйте Free Software Foundation ; Я слышал, что они делают довольно крутые вещи (я имею в виду это, и я уважаю FSF и OSS).

С другой стороны, если вы работаете над проектом, в котором ожидается взрывной рост использования (хотя такие прогнозы почти никогда не бывают точными), вам лучше заложить какую-то прочную основу с наилучшим требуемым качеством кода, так как почти наверняка обслуживание будет быть большей стоимостью для проекта.

Программисты любят «чистый» код, что бы это ни значило. Мы даже не можем договориться о том, что чисто, но нам это нравится. Однако иногда это не так важно, как юзабилити и правильность. Это может показаться синонимом, но это не так - если вы видели код, написанный настоящим хакером Perl за 4 часа с намерением использовать его дважды и выбросить, вы признаете, что он не чистый, но он работает.

Поэтому иногда, не обращая внимания на эго, мы должны просто заставить его работать. Обратите внимание, что я не рекомендую писать плохой код как привычку; Я просто указываю, что это может быть необходимо. Совершенство требует времени, которого ваша компания может не иметь. Поэтому, если ваш работодатель не против, создайте программное обеспечение, но если вам нужно, просто напишите рабочий код, не обращайте внимания на «чистоту». Это просто ответ «Один размер подходит всем» - вы должны расставить приоритеты.

Я не уверен, что "хорошо выглядеть" и быть "элегантным, совершенно понятным и легко обслуживаемым" эквивалентно.

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

Я не вижу каких-либо недостатков, кроме возникающих затрат во времени.

Чтобы код «хорошо выглядел», существует множество автоматизированных инструментов, которые будут правильно делать отступы и расставлять все по вашему желанию.

Слишком много всего никогда не приносит пользы.

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

Поэтому поддержание определенного уровня чистоты в коде выгодно не только вашим коллегам-разработчикам. Не тратьте на это слишком много времени (упомянуто ~ 5%). Научитесь использовать инструменты своего ремесла для автоматизации ручных заданий (в данном случае форматирование кода). Возьмите на себя ответственность за то, что вы делаете, и всегда делайте то, что вы считаете наиболее полезным для вашей компании / клиентов / пользователей.

Это цитата из «Чистого кода» Боба Мартина:

Чтобы донести эту мысль до дома, что, если бы вы были врачом и имели пациента, который требовал от вас прекратить всякую глупую стирку рук при подготовке к операции, потому что это занимало слишком много времени? Ясно, что пациент является боссом; и все же врач должен полностью отказаться от подчинения. Почему? Потому что врач знает больше, чем пациент, о рисках заболеваний и инфекций. Было бы непрофессионально (не говоря уже о преступности) для врача соблюдать пациента.

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

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

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

Конечно, бывают случаи, когда кто-то программирует что-то с единым стилем кода, и это все равно сводит меня с ума. Особенно код, который не «дышит». Например:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Хорошо ... Это выглядит хуже с методами Objective C, и с большим количеством вложенных операторов if и строк, намного длиннее, чем 80 символов. Но это все равно меня раздражает :)

Я делаю все возможное, чтобы очистить код. Я думаю, что это очень помогает выявить ошибки.

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

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

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

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

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

Это кусок кода, демонстрирующий мой стиль кодирования.

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

Я пишу код, который пытается решить данную проблему наиболее эффективным и теоретически «элегантным» способом. В этом смысле только это чисто. Если это произойдет, когда я закончу, пусть будет так.

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

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

Чистый код хорош, но, как и все остальное, он должен быть достаточно чистым. Отступ 5 строк кода 4 пробела и одна строка 5 пробелов не увеличивают трудность чтения.

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

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

Но также это зависит от того, что вы подразумеваете под «чистым кодом».

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

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

int foo    = 1;
int bar    = 2;
int foobar = 3;

легче читать, чем

int foo = 1;
int bar = 2;
int foobar = 3;

а это значит, что легче отсканировать, когда вы будете позже отлаживать.

Кроме того, в PHP вы можете использовать любое количество блоков случайного кода. Я использую их для группировки логических задач:

// do x
{
    // ...
}

// do y
{
    // ...
}

Это добавляет четкое определение к соответствующему коду.

Редактировать : в качестве дополнительного бонуса легко предшествовать одному из этих блоков логического кода, if (false)если вы хотите временно пропустить его.

Я просто пишу свой код, следуя стандартам компании. Если я хочу, чтобы это было «красиво», я могу запустить его через кодовое украшение.