Есть ли какая-то польза от одержимости созданием кода «красиво»?

Иногда я трачу смехотворное количество времени (часов) на то, чтобы сделать код «красивым». Я имею в виду, чтобы все выглядело симметрично. Я на самом деле быстро прокручиваю весь класс, чтобы увидеть, не выпрыгивает ли что-нибудь как не «красивое» или «чистое».

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

Я просто полностью ОКР или в этом есть какая-то польза?

Используйте автоформатер. Если вы действительно тратите столько времени на ручное редактирование кода, я хотел бы предположить, что вам не очень скучно / скучно, потому что для этого нет абсолютно никаких причин. Ctrl + K, Cntrl + D в VS отформатирует весь документ. Вы можете использовать что-то вроде Style Cop, если хотите что-то более тяжелое.

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

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

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

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

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

Например, когда объявляются переменные в классе, мне нравится иметь логические группировки - это облегчает следование логике.

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

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

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

Когда-нибудь кто-то должен будет поддержать ваш код. Чистый код гораздо проще поддерживать. И однажды это может быть ты. Через 6 месяцев или год ты не вспомнишь, что сделал. Но если он чистый и легкий для чтения, он скоро вернется.

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

Нет - быть одержимым тем, чтобы код выглядел красиво, не имеет смысла .

Вот некоторые кусочки мудрости, которые я нашел полезными:

Спросите, почему код должен быть аккуратным.

Вы можете или не можете тратить свое время в зависимости от вашего определения довольно.

Фундаментальная теорема форматирования гласит, что хорошая визуальная компоновка показывает логическую структуру программы. Делать код красивым стоит чего-то, но стоит меньше, чем показывать структуру кода. [стр. 732, Code Complete 2-е издание, Стив Макконнелл]

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

Это усложнит обнаружение изменений и вызовет ненужные конфликты слияния, если другие члены команды редактируют файл. Если вам необходимо внести изменения в форматирование, убедитесь, что другие члены группы не работают с этим файлом. [Перефразировано, стр. 93, Прагматическое управление версиями с использованием Subversion, 2-е издание]

Также Мартин Фаулер говорит о «ношении двух шляп» и переключении между ними в течение дня. Одна шляпа для добавления функций, одна шляпа для рефакторинга.

1. Вы рассматриваете возможность добавления новой функции (Feature Hat)
2. Вы просматриваете существующий код, чтобы получить понимание, приводя порядок в порядок. (Рефакторинг Hat)
3. Зафиксируйте изменения.
4. Добавьте функцию. (Feature Hat) и так далее ....

[Перефразированный pg 57ish, Refactoring, Martin Fowler]

Так что не тратьте часы, пытаясь оптимизировать всю кодовую базу. Просто добавьте достаточно кода, чтобы добавить следующую функцию.

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

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

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

Это немного помогает, но не стоит тратить на это много времени. Также убедитесь, что ваши улучшения также добавляют переменную область видимости, RAII, групповое копирование / вставленный код и т. Д. Если вы сделаете все это, вам станет в 1000 раз легче, если вы поймете, что код делает через год или около того.

Вы должны создать чистый код, но это не должно занять несколько часов.

Для C есть gnu-программа gnu-indent gnu-indent , в eclipse есть по крайней мере средство форматирования кода для Java, и я думаю, что есть инструменты для большинства других языков. Нужно сделать несколько щелчков мышью, чтобы правильно сделать отступ в файле, и несколько минут, если вы хотите нарушить правила для определенных целей - как я делаю для коротких операторов switch-case:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

что сложно указать.

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

Прочтите эту классическую статью «Делать неправильный код неправильным», и вы поймете, почему люди обычно думают, что отступы (что можно сделать автоматически) тривиальны:

http://www.joelonsoftware.com/articles/Wrong.html

В частности, этот список:

Хорошо, пока я упомянул три уровня достижений как программист:

1 Вы не знаете, очистить от нечистого.

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

3 Вы начинаете пахнуть тонкими намеками на нечистоту под поверхностью, и они нападают на вас достаточно, чтобы протянуть руку и исправить код.

Есть еще более высокий уровень, о котором я действительно хочу поговорить:

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

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

«Часы»? Ну, я бы сказал, что ваш ответ - «а», а не «или»: да, у вас ОКР, но в этом есть некоторая выгода.

Вероятно.

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

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

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

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

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

Вы узнаете проблему (компульсивное поведение) и симптом (одержимое форматирование).

Как насчет причины и лечения?

• Ты работаешь слишком много часов?
• Вы расстроены, скучно, тревожно?
• Какова ваша следующая задача? Это то, что вы не хотите делать?
• Когда у вас был последний отпуск? Продвижение? Признание за достижение?
• Это проблема, связанная с выгоранием?
• Ты на марше смерти?

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

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

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

Вы, кажется, довольно проницательны, и я думаю, что вы, возможно, знаете ответ.

Теперь дайте себе разрешение действовать на это.

Святой бычий!
Вы, ребята, никогда не слышали о отступе?

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

ммм - но он работает только на C и некоторых, но не на всех C ++ .... (wtf? почему GNU не обновляет его?)