Как выглядит код хорошего программиста? [закрыто]

Я программист-любитель (начал с VBA, чтобы сделать Excel быстрее), работаю с VB.NET / C # .NET и пытаюсь изучить ADO.NET.

Один из аспектов программирования, который меня всегда расстраивал, - как выглядит «хорошо»? Я не профессионал, поэтому мне не с чем сравнивать. Что делает программиста лучше? Это:

• Они лучше понимают все объекты / классы / методы на данном языке?
• Их программы более эффективны?
• Дизайн их программ намного лучше с точки зрения лучшей документации, хорошего выбора имен для функций и т. Д.?

Другими словами, если бы я посмотрел на код профессионального программиста, что я бы заметил в первую очередь в его коде относительно моего? Например, я читал такие книги, как «Professional ASP.NET» от Wrox press. Являются ли примеры кода в этой книге «мирового класса»? Это вершина? Сможет ли какой-нибудь опытный программист взглянуть на этот код и подумать, что это хороший код?

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

• Хороший код хорошо организован. Данные и операции в классах подходят друг другу. Между классами нет посторонних зависимостей. Это не похоже на «спагетти».

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

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

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

• Хороший код не «умный». Он делает все просто и очевидно.

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

Я еще не читал ее, но книга, которую я планирую прочитать по этой теме, - это Чистый код Роберта К. Мартина.

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

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

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

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

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

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

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

Ничего не сказано.

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

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

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

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

Следующее следствие:

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

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

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

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

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

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

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

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

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

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

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

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

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

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

• Комментарий правильно
• Структура эффективно
• Документ чисто

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я поддерживаю рекомендацию «Чистого кода» Боба Мартина.

Пару лет назад "Beautiful Code" получил высокую оценку.

Любую книгу МакКоннелла стоит прочитать.

Возможно, «Программист-прагматик» тоже будет полезен.

%

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

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

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

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

На этот вопрос довольно хорошо дан ответ в книге Фаулера «Рефакторинг». Это отсутствие всех «запахов», которые он описывает на протяжении всей книги.

Я не видел «Профессиональный ASP.NET», но был бы удивлен, если он лучше, чем ОК. См. Этот вопрос для некоторых книг с действительно хорошим кодом. (Конечно, все по-разному, но принятый ответ трудно превзойти.)

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

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

1. Корректность и эффективность с проверенными алгоритмами (вместо наивных и специальных хаков)
2. Ясность (комментарий к намерениям применительно к нетривиальным алгоритмам)
3. Полнота, охватывающая основы (соглашение о кодировании, управление версиями, документация, модульные тесты и т. Д.)
4. Лаконичность (СУХОЙ)
5. Надежность (устойчивость к произвольному вводу и прерыванию запросов на изменение)

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

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

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

Состав

Комментарии

Регионы

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

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

Я вижу все как «блоки» или регионы, и в каждом регионе есть свои поясняющие комментарии. Регион может быть «классом Person», и внутри этого региона у меня есть несколько методов для свойств, которые я могу назвать «методами доступа» или тому подобным, и каждое свойство и регион имеют свои собственные поясняющие комментарии.

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

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

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

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

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

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

В хорошем коде вещи названы таким образом, что в тривиальных комментариях нет необходимости.

Хороший код обычно бывает коротким.

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

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

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

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

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

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

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

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

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

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

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

1. Оно работает
2. В нем есть модульные тесты, подтверждающие его работу.

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

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

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

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

У меня есть хороший пример:

Прочтите исходный код GWT (google web takeit), и вы увидите, что каждый дурак его понимает (некоторые английские книги читать сложнее, чем этот код).