Вы обеспокоены эстетикой своего кода? [закрытый]

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

Результат очень полезен, так как однажды мне пришлось поддерживать фрагмент кода, который я написал 5 лет назад. Благодаря удобочитаемости мои собственные фрагменты кода в проекте все еще были удобочитаемыми. Однако другие были более беспечны. Это дало мне простой способ распознать мой собственный код из мусора, который был добавлен каким-то неопытным полупрограммистом / менеджером, который был способен писать макросы только в Word и Excel ...

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

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

Когда код выглядит некрасиво, вы не чувствуете мотивации сохранять его крутым.

И я чувствую, что меня так беспокоит то, что я думаю, что мои коллеги меня ненавидят = P

Я тоже так делаю. Я считаю, что хороший внешний вид кода облегчает чтение и понимание.

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

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

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

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

Если вы имеете в виду идентификацию, я думаю, что это необходимо.

Если вы имеете в виду читабельность (что для меня отличается от эстетически красивого), это также важно.

Если вы хотите, чтобы написанное выглядело как летающие цветы и птицы, тогда нет. Меня это не волнует. : P

Нет, я больше не пытался. Вы не можете победить армию кодовых обезьян.

Только с помощью моего личного проекта я стремлюсь сделать его идеальным.

Да, я бессовестно пытаюсь получить карму StackOverflow глупыми вопросами.

Код Tidy более удобен в обслуживании. Ваш мозг способен выполнять удивительное автоматическое сопоставление с образцом в коде, поэтому вы часто обнаруживаете ошибки и проблемы в коде только потому, что это неправильная «форма». Я считаю аккуратность настолько важной, что написал надстройку VS (AtomineerUtils) для добавления и форматирования комментариев к документам, чтобы свести к минимуму объем работы, который мне нужно выполнять, чтобы поддерживать порядок в моем коде.

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

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

Да. И поскольку «вы [действительно] не можете сражаться с армией обезьян» (если я могу позаимствовать это из одного ответа), я стараюсь сделать это менее болезненным и автоматизировать то, что можно автоматизировать, например, выполнение косметических проверок во время сборки (при необходимости сломается). Другой вариант - автоматическое форматирование кода при фиксации, но я предпочитаю первый.

PS: Я использую Jalopy и Maven для этого при выполнении Java.

Да, у меня должен быть код с отступом от пробелов и табуляцией шириной 4 пробела, и если это код C / C ++ / Java, поместите фигурные скобки в отдельную строку, все остальное сделают макросы Emacs: -)

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

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

Думаю, Роберт Мартин лучше всего описал это в своей книге Чистый код: руководство по Agile. Мастерство создания программного обеспечения

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

Бойскауты Америки имеют простое правило, которое мы можем применить к нашему профессия.

Покиньте палаточный лагерь чище, чем вы нашел.

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

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

Дайте определение «эстетике». Я думаю, что для разных людей это означает разное.

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

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

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

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