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

54

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

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

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

ykombinator
источник
Во всех моих попытках написать «чистый» код в соответствии с устоявшимися принципами, я никогда не находил, что его так легко поддерживать за определенным масштабом, основываясь только на такой предпосылке. Гораздо важнее была его надежность и то, насколько хорошо она была протестирована и насколько хорошо она подходила для своих целей (что может иметь такое же отношение к реализации, как и дизайн). Вся чистота в мире не может восполнить недостаток любого из них, и иногда самый надежный код, который я продолжаю использовать, не самый чистый, в то время как мой самый чистый не всегда был самым надежным.
Поэтому превыше всего - над читабельностью, красотой, твердым телом и всем остальным - я считаю полезным расставить приоритеты надёжности и «стабильности» (качество неизменности в моей книге, а также отсутствие необходимости или желания измениться). в дальнейшем). Надежные и стабильные вещи - это вещи, которые прошли испытание временем для меня, и иногда они не очень чисты по книгам многих людей (некоторые из моих самых повторно используемых кодов - это код на C, относящийся к концу 80-х и началу 90-х годов). который применяет такие вещи, как взломанные биты, которые почти никто не понимает - все еще работает так надежно).

Ответы:

52

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

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

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

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

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

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

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

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

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

губки
источник
45
Пока ваш технический долг ( en.wikipedia.org/wiki/Technical_debt ) не приводит вас к «техническому банкроту» (невозможно доставить новые функции, исправить одну часть, сломать другую и т. Д.) И следить за этим на это я согласен.
Матье
3
@HeathLilley Согласен. Я просто не верю разработчикам, которые говорят, что должен быть написан только чистый код. Это фальшивка. Грязный код бывает. Идея, что разработчики должны писать только чистый и правильный код с самого начала, является иллюзией. Я продвигаю идею, что мы всегда пересматриваем и проводим рефакторинг, когда наше понимание предметной области улучшается.
Спонг
40
Проблема с «просто отправь эту чертову штуку сейчас» состоит в том, что руководство не купит твои причины для рефакторинга позже, но если ты сделаешь это незаметно СЕЙЧАС, все будет хорошо.
Работа
5
Еще одна иллюзия - думать, что у тебя будет время почистить это позже. Этого не произойдет. У вас будут другие вещи для отправки. Вы не должны доставлять грязный код. И, кстати, вы тоже должны работать в сжатые сроки, вы технический специалист, который знает, сколько времени потребуется, чтобы написать чистый код. Это не означает, что вы будете чистить и перерабатывать в течение безумного количества времени, это означает, что нужно учитывать время на рефакторинг до того, как вы отправите код.
Стив Chamaillard
3
"Вы можете рефакторинг это позже" [цитата нужна]
Карл Лет
39

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

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

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

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

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

user2567
источник
13
Ну, я полирую, пока код не станет понятным для меня. Если я вернусь через две недели и мне придется выяснить, что я сделал, то, вероятно, другим будет недостаточно ясно понять.
Роберт Харви
14
Элегантный код по своей природе более удобен в обслуживании, и, я думаю, его легче читать.
Крейг,
6
+1, я видел какой-то совершенно стильный КОД СПАГЕТТИ в прошлом.
Jas
23
Я согласен с мнением, но я пишу свой код с правильным количеством пробелов между членами, и меня раздражают люди, которые этого не делают. Это легко сделать (еще проще, благодаря автоматизированным инструментам, таким как StyleCop), а согласованность, которую он обеспечивает, стоит небольших усилий.
Роберт Харви
3
@sunpech: напишите это чисто, и намного легче содержать это в чистоте.
Дэвид Торнли
24

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

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

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

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

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

Benjamin Wootton
источник
2
Нет, вы очищаете свой код, когда есть время и бюджет, И риск этого меньше, чем риск не делать этого. В производственных средах это часто означает, что вы не собираетесь полировать существующий код, чтобы сделать его более красивым, просто он не рентабелен, но создает риск появления новых ошибок.
2012 года
Это также зависит от того, в каком уголке разработки программного обеспечения вы работаете. Я работал в агентстве по цифровому маркетингу, которое было более чем радо перенести расходы на своего клиента, если следующий этап займет больше времени из-за проблем с кодовой базой. Наше стремление уделять больше времени в ходе разработки для исправления существующих проблем было сбито в пользу увеличения времени разработки, равного большему количеству денег для бизнеса.
Саймон Уайтхед
1
Я согласен с этим, вы должны доставлять код, но если вы не можете исправить / обновить / обновить, то, что вы доставили, был не код, а дыра в деньгах. Я считаю, что люди, которые борются с этой идеей, привыкли работать в плохих условиях и утверждают систему, которую они никогда не испытывали. Я поддерживал как чистый, так и не чистый код и скажу вам, что чистый код гораздо дешевле и быстрее поддерживать и разрабатывать.
Jdahern
21

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

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

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

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

Sifar
источник
Я бы не согласился - программное обеспечение не ржавеет (как выразился Джоэл), в отличие от внутренней части автомобиля. Вы можете утверждать, что при обновлении ОС программное обеспечение тоже должно обновляться, но это нечто иное. Кроме того , я сделать запись чистого кода, но я не думаю , что это наиболее важная характеристика моих вкладов.
К.Стефф
18

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

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

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

GrandmasterB
источник
15

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

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

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

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

Satanicpuppy
источник
Согласовано. Большинство людей не собираются писать чистый код для отправки / выпуска в первый раз. Для выполнения работы используется клейкая лента.
Spong
2
Хватит с клейкой ленты! Спольский не бог. Он ставит штаны на одну ногу в то время, как мы!
Работа
5
Одна из причин, по которой вы пишете чистый код, заключается в том, что писать чистый код быстрее, чем «грязный» код, на любой, кроме самой короткой временной шкале (скажем, несколько часов). Если в течение нескольких секунд размышления о именах переменных и методов заставят вас пропустить крайний срок, то вы потеряете драгоценное время, когда вы и / или ваши коллеги запутаются в вашем коде. Вы делаете код звучащим почти одноразовым, как вы напишите его, он будет использоваться некоторое время без обслуживания, а затем удалится. Может быть, в вашей специфической ситуации код одноразовый. Я никогда не видел, чтобы это случилось за десятилетие практического опыта.
PeterAllenWebb
1
@peter: И за два десятилетия я никогда не видел места, где каждый кусок кода был бы чистым. Я редко даже видел место, где была половина . Где вы работаете? NASA?
Satanicpuppy
2
@Satanicpuppy Я видел много грязного кода в свое время, и я написал свою долю, но почти все это тратило мое или чужое время. Я поддерживаю утверждение, что чистый код на самом деле может быть написан БЫСТРЕЕ, чем грязный код в любом масштабе времени, превышающем несколько часов.
PeterAllenWebb
7

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

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

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

Heath Lilley
источник
5

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

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

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

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

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

dss539
источник
4

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

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

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

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

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

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

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

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

K.Steff
источник
3

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

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

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

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

back2dos
источник
2
Это вызывает у меня еще большее раздражение, когда я вижу плохо отформатированный код. Человек, пишущий это, мог просто использовать один из этих инструментов, чтобы сделать это для них. Это также чаще всего происходит при смешивании вкладок и пробелов, чтобы создать нечестивый беспорядок.
Йтернберг
3

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

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

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

Пер Ноалт
источник
3

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

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

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

Тулаинс Кордова
источник
2

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

chiurox
источник
2

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

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

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

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

vedosity
источник
2

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

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

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

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

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

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

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

user20416
источник
1

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

ElGringoGrande
источник
Как крыло или (что еще хуже) комментарии, скажем?
Дэвид Торнли
1

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

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

Куртис
источник
1

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

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

JeffO
источник
1

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

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

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

user7007
источник
0

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

user281377
источник
0

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

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)если вы хотите временно пропустить его.

Craige
источник
11
Я думаю, что они уже изобрели что-то, что делает это - это называется функцией. Каждый раз, когда вы создаете один из этих блоков, вы должны вместо этого создать функцию. Оттуда, если вы не хотите запускать его, закомментируйте вызов функции (вместо того, чтобы
вводить
1
@ stargazer712: Я ненавижу функции php из-за отсутствия определенных пространств имен. Неизбежно, читая чей-то другой код, у него есть одно «включение» вверху, которое само включает в себя 5 других вещей, каждая из которых включает еще 4, и затем мне нужно выполнить поиск по всей базе кода, чтобы найти определение функции. Очень расстраивает.
Satanicpuppy
Часто это код, который не гарантирует объявление функции. например. нет возможности для повторного использования, вычисления / установки связанных локальных переменных и т. д.
Крейг,
с другой стороны, код без возможности повторного использования встречается редко. Если вы обнаружите, что пишете много кода, который нельзя использовать повторно, есть большая вероятность, что он может быть улучшен ... значительно.
riwalk
-2

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

Muad'Dib
источник
2
За исключением того, что обычно происходит, когда кто-то другой заканчивает тем, что пропустил это через украшение, пытающееся очистить то, что вы не удосужились очистить.
riwalk
@ Stargazer712, именно поэтому я не слишком беспокоюсь о соблюдении стандартов компании
Muad'Dib,
@ Maud'Dib, проблема в том, что результат так же хорош, как и украсить. В то время как горизонтальное пустое пространство целиком связано с областью действия (и поэтому очень хорошо очищается), вертикальное пустое пространство обычно предназначается для цели (группирует то, что связано) и очищает очень плохо Итог - помилуй своих коллег-разработчиков.
riwalk
@ Stargazer712 Проблема в том, что, за исключением «стандартов компании», все остальное - дело вкуса, которое субъективно. например, я люблю размещать места там, где мой коллега их ненавидит. Я делаю это хорошо для меня, и это так далеко, как я иду.
Муад Диб
1
Будьте осторожны с "beautifiers", так как они могут испортить слияние коммитов (у меня есть опыт из первых рук :)).
Юха Унтинен