сентиментальный код [закрывается]

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

if(MyChecksAreOk()) { Code to execute }

...

private bool MyChecksAreOk()
{ 
    return ConditionOne && ConditionTwo && ConditionThree;
}

Это условия только полагаются на локальные переменные объема, Вы могли сделать новые функциональные помехи и передать во всем, в чем Вы нуждаетесь. Если существует соединение, передача в локальном материале.

10
задан 8 revs, 4 users 70%unknown 29 July 2015 в 01:12
поделиться

11 ответов

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

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

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

С того дня я перестал быть привязанным к моему коду. Если я'

34
ответ дан 3 December 2019 в 13:13
поделиться

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

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

14
ответ дан 3 December 2019 в 13:13
поделиться

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

2
ответ дан 3 December 2019 в 13:13
поделиться

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

На ум приходят две цитаты:

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

- Брайан Керниган

и

« Сделайте все настолько просто, как возможно, но не проще ».

- Альберт Эйнштейн

6
ответ дан 3 December 2019 в 13:13
поделиться

Я публикую фрагмент из блога Джеффа Этвуда, Сосание меньше каждый год , и я согласен на 100%.

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

8
ответ дан 3 December 2019 в 13:13
поделиться

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

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

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

  • совместное владение кодом : Здесь есть два лагеря: дать людям больше владения своим кодом и надеяться, что гордость возьмет верх, или дать им меньше и позволить давлению со стороны сверстников. Я считаю, что предоставление людям большей ответственности может привести к восхищению этим кодом. Мы практикуем совместное владение кодом, поэтому я постоянно вынужден видеть, как кто-то переписывает мой идеальный код, чтобы сделать его лучше (по их мнению). Я быстро понял, что слишком много восхищаться этим было пустой тратой времени и эмоционально сложно.

  • парное программирование : работа бок о бок с кем-то сохранит вашу реалистичность.

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

2
ответ дан 3 December 2019 в 13:13
поделиться

Я работаю с PurplePilot - я не восхищаюсь своим собственным кодом, и поэтому я постоянно ищу новые, более эффективные (черт возьми, более простые) способы сделать то же самое. Мне нравится книга «Эффективный C #», я почерпнул оттуда много полезного кода, которым я восхищаюсь.

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

Возникает более широкий вопрос: если код не выброшен или, по крайней мере, пересмотрен, то разработка на библиотеках, которые перестают работать, - это хорошо?

1
ответ дан 3 December 2019 в 13:13
поделиться

Два слова: проверка кода.

Соберите двух или более товарищей-разработчиков и пригласите их на обзор / критику / прокомментируйте свой код. «Она пролила некоторый (правда, резкий) свет на ваш код».

0
ответ дан 3 December 2019 в 13:13
поделиться

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

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

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

1
ответ дан 3 December 2019 в 13:13
поделиться

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

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

0
ответ дан 3 December 2019 в 13:13
поделиться

Джонатан Эдвардс написал впечатляюще красивое эссе на эту тему, вдохновленное работой над книгой О'Рейли Beautiful Code . Вот последний абзац, но остальная часть эссе тоже стоит прочитать.

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

Другие версии этой мудрости существуют и в других областях. Сэмюэл Джонсон, о написании:

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

Версия Уильяма Фолкнера была гораздо более лаконичной: «Убейте своих любимых.

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

Мое эссе «Моя эволюция как программиста» (который я бы связал, если бы я не был новым пользователем), в основном касается изучения скептицизма по поводу написанного мной кода: работает ли он, полезен ли он, понятен ли (парное программирование было настоящим тревожным сигналом Вот). Это сложно!

3
ответ дан 3 December 2019 в 13:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: