Вы обеспокоены эстетикой вашего кода?

Ответ 1

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

Ответ 2

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

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

Ответ 3

Я думаю, что Роберт Мартин описал это лучше всего в своем "Кодексе чистой книги": "Справочник по гибким" Программное мастерство

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

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

Оставьте уборщик кемпинга, чем вы нашел его.

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

Я тоже это делаю. Я считаю, что улучшение качества кода упрощает чтение и понимание.

Ответ 10

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

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

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

"Pretty" и "code aesthetics" - это своего рода прокси-слова - эти термины звучат тривиально, но (по крайней мере, для меня) действительно означают "четко и логически выраженные идеи". Четко и логически выраженные идеи имеют значение.

Ответ 14

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

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

Ответ 15

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

Ответ 16

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

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

Ответ 17

Определите "эстетику". Я думаю, что это разные вещи для разных людей.

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

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

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

Ответ 18

Итак, ваш парень делает слияние полного кошмара? Отменив все форматирование, которое мне эстетически нравится, писатель и основной сторонник этого кода, который вы только что проверили?

Ответ 19

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