Как выглядит хороший код программиста?

Ответ 1

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

• Хороший код хорошо организован. Данные и операции в классах совпадают. Не существует посторонних зависимостей между классами. Это не похоже на "спагетти".

• Хорошие комментарии к коду объясняют, почему делаются не то, что сделано. Сам код объясняет, что сделано. Потребность в комментариях должна быть минимальной.

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

• Хороший код хорошо протестирован. Тесты служат исполняемой спецификацией кода и примерами его использования.

• Хороший код не "умный". Это делает вещи простыми, очевидными способами.

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

Я еще не читал, но книга, которую я планирую читать на эту тему, Clean Code от Robert C. Martin.

Ответ 2

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

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

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

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

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

Ответ 3

Цитата Фаулера, суммирующая читаемость:

Любой дурак может написать код, который может понять компьютер.
Хорошие программисты пишут код, который люди могут понять.

'сказал.

Ответ 4

Лично мне придется процитировать Тим Питерс "Дзен Питона". Он говорит программистам на Python, как выглядит их код, но я обнаружил, что он применим к основному коду.

Красивая лучше, чем уродливая.
Явно лучше, чем неявный.
Простой лучше, чем сложный.
Комплекс лучше чем сложный.
Плоский лучше, чем вложенный.
Редкий лучше, чем плотный.
Показатели удобочитаемости.
Специальные случаи не являются достаточно сложными, чтобы нарушать правила.
Хотя практичность бьет чистоту.
Ошибки никогда не должны проходить молча.
Если явно замалчивается.
Перед лицом двусмысленности откажитесь от соблазн угадать. Должен быть один - и желательно только один - очевидный способ сделать это.
Хотя этот способ может быть не очевидным сначала, если вы не голландский.
Теперь лучше, чем никогда.
Хотя никогда не бывает лучше, чем сейчас.
Если реализация трудно объяснить, это плохая идея.
Если реализация легко объяснить, это может быть хорошей идеей.
Пространства имен - одна хорошая идея - позвольте сделать еще больше!

Ответ 5

Код - это поэзия.

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

A следует из следствия:

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

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

Второе следствие:

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

Третье следствие:

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

Ответ 6

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

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

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

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

Ответ 7

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

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8& S = книги & QID = 1229267173 & ср = 8-1

Ответ 8

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

Все программисты на компетентном уровне:

• Комментарий правильно
• Эффективная структура
• Очистить документ

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

Это, на мой взгляд, ум умного программиста. Тот, кто видит мир в терминах правил и логики и в конечном итоге подчиняется этим правилам при разработке и написании программы.

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

Ответ 9

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

По-моему, хороший код программиста - это язык-агностик; хорошо написанный код может быть прочитан и понят за короткий промежуток времени с минимальным мышлением, независимо от используемого языка программирования. Является ли код в Java, Python, С++ или Haskell, хорошо написанный код понятен людям, которые даже не программируют на этом конкретном языке.

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

Например, на днях я просмотрел код TinyMCE, чтобы ответить на один из вопросов о переполнении стека, Это написано на JavaScript, язык, который я едва использовал. Тем не менее, из-за стиля кодирования и комментариев, которые включены, наряду с структурированием самого кода, это было довольно понятно, и через пару минут я смог перемещаться через код.

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

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

Ответ 10

• Легко читаемый
• легко писать
• легко поддерживать

все остальное - филигрань

Ответ 11

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

Ответ 12

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

Ответ 13

Вместо того, чтобы повторять все остальные замечательные предложения, я вместо этого предлагаю вам прочитать книгу Code Complete от Steve McConnell

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

Ответ 14

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

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

Что касается взгляда на книги, я бы сказал, что определенно не в своем опыте. Посмотрите на API и фреймворки и кодовые соглашения и код других людей и используйте свои собственные инстинкты и попытайтесь понять, почему материал такой, какой он есть, и каковы последствия вещей. То, что код в книгах почти никогда не делает, - это план для незапланированных, что и делает проверка ошибок. Это только окупается, когда кто-то отправляет вам электронное письмо и говорит: "Я получил ошибку 321" вместо "эй, приложение сломано, лет".

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

Ответ 15

[Чисто субъективный ответ]
Для меня хороший код - это форма искусства, как живопись. Я мог бы пойти дальше и сказать, что это на самом деле рисунок, который включает в себя символы, цвета, "форму" или "структуру" кода и все это является настолько читаемым/исполняемым. Сочетание читаемости, структуры (то есть столбцов, отступов, даже имен переменных одинаковой длины!), Цвета (имена классов, имена переменных, комментарии и т.д.) Делают все, что мне нравится видеть как "красивую" картину, которая может сделайте меня очень гордым или очень ненавидящим мой собственный код.

(Как уже говорилось, очень субъективный ответ. Извините за мой английский.)

Ответ 16

Во-вторых, рекомендация Боба Мартина "Чистый код".

"Красивый код" был высоко оценен пару лет назад.

Любые книги Макконнелла заслуживают внимания.

Возможно, "Прагматический программист" тоже будет полезен.

%

Ответ 17

Об этом очень хорошо сказано в книге Фаулера "Рефакторинг". Это отсутствие всех "запахов", которые он описывает на протяжении всей книги.

Ответ 18

Я не видел "Professional ASP.NET", но я был бы удивлен, если бы это было лучше, чем ОК. См. этот вопрос для некоторых книг с действительно хорошим кодом. (Разумеется, это зависит, но принятый ответ трудно превзойти.)

Ответ 19

Это, по-видимому, (должно быть) FAQ. Существует статья ACM о прекрасном коде недавно. Кажется, что много внимания уделяется легкому чтению/пониманию. Я бы определил это с помощью "простого для чтения/понимания специалистами домена". Действительно, хорошие программисты склонны использовать лучшие алгоритмы (вместо наивных простых для понимания алгоритмов O (n ^ 2)) для любых заданных проблем, которые могут быть труднодостижимыми, если вы не знакомы с алгоритмом, даже если хороший программист дает ссылку на алгоритм.

Никто не идеален, включая хороших программистов, но их код, как правило, стремится:

• Правильность и эффективность с проверенными алгоритмами (вместо наивных и adhoc hacks)
• Ясность (комментарий для намерения применительно к нетривиальным алгоритмам)
• Полнота для охвата основ (соглашение о кодировании, управление версиями, документация, модульные тесты и т.д.).
• Чрезвычайная сущность (DRY)
• Надежность (устойчивость к произвольному вводу и нарушение запросов на изменение)

Ответ 20

Вторые рекомендации для дяди Боб "чистый код". но вы можете взглянуть на http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091, поскольку я думаю, что это касается вашего конкретного вопроса немного лучше. хороший код должен перескочить со страницы и рассказать вам, что он делает/как это работает.

Ответ 21

Джефф Этвуд написал хорошую статью о том, как кодировщики являются первой ссылкой: http://www.codinghorror.com/blog/archives/001188.html

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

Структура

Комментарии

Регионы

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

Теперь программирование различных приложений и на разных языках, таких как Java, С#, Assembler, С++, C, я пришел к "стандартному" написанию, которое мне нравится.

Я вижу все как "коробки" или регионы, и каждый регион объясняет это комментированием. Область может быть "классом", и внутри этого региона у меня есть несколько методов для свойств, которые я могу назвать "Способы доступа" или такие, и каждое свойство и область имеют свои собственные объяснения комментариев.

Это очень важно, я всегда вижу свой код, который я делаю, поскольку "являюсь частью api" при создании структуры API и элегантности важна ОЧЕНЬ.

Подумайте об этом. Также прочитайте мою статью о Communication issues when adapting outsourcing, которая объясняет грубо, как плохой код может конфликтовать, Enterpret, как вам нравится: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Ответ 22

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

Ответ 23

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

Ответ 24

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

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

Хороший код имеет вещи, названные таким образом, чтобы ненужные ненужные комментарии.

Хороший код имеет тенденцию быть коротким.

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

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

Ответ 25

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

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

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

Ответ 26

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

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

Таким образом, его код должен:

• Работа (неважно, как быстро код получает неправильный ответ. В реальном мире нет частичного кредита).
• Объясните, как он знает, что этот код работает. Это комбинация документации (javadoc - мой выбор), обработка исключений и тестовый код. В очень реальном смысле, я считаю, что строка для строки, тестовый код более ценна, чем функциональный код, если не по какой-либо другой причине, чем объясняет "этот код работает, вот как он должен использоваться, и именно поэтому я должен получить заплатил".
• Поддерживаться. Мертвый код - это кошмар. Обслуживание устаревшего кода - это тяжелая работа, но это нужно сделать (и помните, что это "наследие" в тот момент, когда он покидает ваш стол).

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

• Одержим форматированием. Существует множество IDE, редакторов и симпатичных принтеров, которые могут форматировать код в соответствии с тем стандартным или личным предпочтением, которое, по вашему мнению, является подходящим. Я использую Netbeans, я настраивал параметры формата один раз и время от времени нажимаю alt-shift-F. Решите, как вы хотите, чтобы код выглядел, настраивал среду и позволял инструменту выполнять работу.
• Одержимы соглашениями об именах за счет человеческого общения. Если соглашение об именах ведет вас по дороге, назвав ваши классы "IElephantProviderSupportAbstractManagerSupport", а не "Zookeeper", измените стандарт, прежде чем сделать его труднее для следующего человека.
• Забудьте, что он работает как команда с реальными людьми.
• Забудьте, что основной источник ошибок кодирования находится сейчас на его клавиатуре. Если есть ошибка или ошибка, он должен сначала взглянуть на себя.
• Забудьте о том, что происходит вокруг. Любая работа, которую он делает сейчас, чтобы сделать его код более доступным для будущих читателей, почти наверняка принесет ему пользу напрямую (потому что кто будет первым, кто попросит посмотреть его код?).

Ответ 27

Если вы пишете код на С++, есть очень хорошая книга с отличными стандартами кодирования, на которые мы ссылаемся в uni, которая называется: " Стандарты кодирования С++: 101 правило, рекомендации и рекомендации" "Herb Саттер, Андрей Александреску и Бьярн Страуструп.

Ответ 28

• Работает
• Он имеет модульные тесты, которые доказывают, что он работает

Остальное - обледенение...

Ответ 29

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

Ответ 30

По иронии судьбы лучше программист менее незаменимый он/она становится потому, что полученный код лучше обслуживается кем-либо (как указано общим согласием Эрана Гальперина).

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