Что значит писать «хороший код»? [закрыто]

41

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

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

Так что значит писать «хороший код»? Что такое "хороший код"?

gablin
источник
15
Хороший код - это если вы посмотрите на него через два года, и ваша первая мысль - не «Чувак, веселье».
Бобби

Ответы:

91

Хороший кодер похож на хорошего игрока в пул.

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

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

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

Макнейл
источник
10
«Хороший кодер пишет код, который выглядит так, как будто это легко и просто сделать». << ТОЧНО! Я думаю, это потому, что люди обычно думают, что хороший программист - это тот, кто может писать очень «умные» хаки. Если код чистый и не слишком «умный», он должен быть простым, верно?
hasen
3
Мои 2 цента: когда у вас есть язык с автоматическим рефакторингом EASY - Java и C # - это два примера, которые я знаю лучше всего - легко итеративно переходить к хорошему коду. В противном случае вы должны хорошо осмыслить в первую очередь, но там есть своего рода проблема куриного яйца.
Дэн Розенстарк
3
Некоторые алгоритмы по своей сути сложны. У хорошего кодировщика не должно быть проблем с написанием их, когда они действительно необходимы, и сохранением их как можно более читабельными.
J-16 SDiZ
2
@hasenj: да, это из-за этой леммы: глупые люди пишут код, понятный компилятору. Умные люди пишут код, глупые люди понимают.
v.oddou
49

WTF в минуту

( оригинал )


РЕДАКТИРОВАТЬ: Основная идея заключается в том, что «качество кода» не может быть введено в правила, так же, как вы не можете включить «хорошее искусство» или «хорошую поэзию» в правила, так что вы можете позволить компьютеру определить «да, хорошее искусство» или "Нет, плохая поэзия". В настоящее время единственный способ - понять, насколько легко понять код для других людей.


источник
1
У нас это застряло на нашей доске на работе :-)
Никто
1
@Cape Cod Gunny также была в книге дяди Боба
mlvljr
2
Помимо того, что это отличный мультфильм, я думаю, что это действительно важно - хороший код - это код, который другие люди находят приятным для чтения и сопровождения.
FinnNk
1
Итак, хороший код - это любой код, который не является плохим. Например, трудно определить хороший код, легче определить плохой код.
Эрнелли
5
Обычно я нахожу, что те «WTF?» На хорошей встрече кода вскоре сопровождаются «О-о-о-о, ладно ... я вижу, что ты сделал, тара».
AndrewKS
7

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

«WTF за минуту» (выше) - правда, но это всего лишь следствие более общего правила. Чем больше WTF, тем медленнее понимание.

mojuba
источник
1
@rmx: определите «хорошо выполнять свою работу»
моджуба
2
Хорошо, что RemoveCustomerметод на самом деле удаляет кутомер без провала. Вы можете часами делать так, чтобы это выглядело красиво, но это не значит, что на самом деле это работает. «Как быстро вы понимаете код» - не единственный критерий «хорошего кода» - вот что я говорю.
Никто
2
@rmx: но подразумевается отсутствие ошибок, не так ли? Если ваш код не выполняет работу должным образом, это не код (пока).
Моджуба
4
@rmx: на самом деле нет. Если ваш код легко понять, то в заключение легко понять, если он плохо работает. OTOH, если это трудно понять, это трудно понять, если он вообще выполняет свою работу.
pillmuncher
2
@rmx: PS Проще говоря, ваш декремент () - это классический WTF, и поэтому он замедляет понимание частей кода, где используется эта функция
mojuba
5

Вы знаете, что пишете хороший код, когда ...

  1. Клиент доволен
  2. Товарищи коллеги заимствуют ваш код в качестве отправной точки
  3. Новому парню / галу только что сказали внести изменения в систему, которую вы построили 6 месяцев назад, и он ни разу не задал вам вопрос
  4. Ваш начальник просит вас разработать новые виджеты для использования командой
  5. Вы смотрите на код, который пишете сегодня, и говорите себе: «Хотел бы я, чтобы этот код был написан два года назад».

Как вы оцениваете, хорош ли код ...

  • Какое время отклика?
  • Сколько поездок на сервер это делает?
  • Вы бы лично использовали приложение или думаете, что оно неуклюжее?
  • Вы бы построили это так же в следующий раз?

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

Майкл Райли - AKA Gunny
источник
2
«Клиент счастлив» ортогонален этому.
1
@TRA - Если клиент доволен, это означает, что вы поняли требования и предложили решение, которое они ожидали.
Майкл Райли - AKA Gunny
6
конечно, но плохой код может сделать то же самое.
4

Код, который

  1. без ошибок

  2. многоразовый

  3. независимый

  4. менее сложный

  5. хорошо задокументированы

  6. легко изменить

называется хорошим кодом.

Хорошая программа работает без нареканий и не имеет ошибок. Но какие внутренние качества создают такое совершенство? Это не загадка, нам просто нужно время от времени напоминать. Неважно, кодируете ли вы на C / C ++, C #, Java, Basic, Perl, COBOL или ASM, все хорошее программирование демонстрирует одни и те же проверенные временем качества: простота, удобочитаемость, модульность, многоуровневость, дизайн, эффективность, элегантность и ясность, эффективность, элегантность. и ясность

Источник: MSDN

Чанки патхак
источник
Простота, удобочитаемость, элегантность и ясность - это одно и то же. Модульность и многослойность - это всего лишь способы сделать ваш код понятным и элегантным. Единственное, что остается в списке, это эффективность, которая подразумевается, и к тому же это часто вопрос компромисса между эффективностью и ясностью.
Моджуба
Проверьте это: goo.gl/hdQt8
Chankey Pathak
2
Код может быть без ошибок?
Кейси Паттон
Нет, не может. (Практически)
Чанки Патхак
Эффективные должны быть добавлены в ваш список. Скорость не обязательно является основным показателем хорошего кода, но хороший код не должен быть излишне медленным или расточительным.
Калеб
3

Это кажется знакомым?

Philips предоставил мне возможность наблюдать за дизайном нового продукта. По мере развития я становился все более неловким и начал рассказывать о своих заботах своему руководителю. Я неоднократно говорил ему, что дизайны не были «чистыми» и что они должны быть «красивыми», как и дизайны Дейкстры. Он не нашел это полезным комментарием. Он напомнил мне, что мы были инженерами, а не художниками. В его уме я просто выражал свой вкус, и он хотел знать, какой критерий я использовал при принятии решения. Я не смог ему сказать! Поскольку я не мог объяснить, какие принципы нарушались, мои комментарии просто игнорировались, и работа продолжалась. Чувствуя, что должен быть способ объяснить и мотивировать мой «вкус», Я начал пытаться найти принцип, который отличал бы хороший дизайн от плохого. Инженеры очень прагматичны; они могут восхищаться красотой, но они ищут полезности. Я пытался найти объяснение, почему «красота» была полезна.

Пожалуйста, посмотрите остальное здесь .

mlvljr
источник
1
Поскольку ссылка в сообщении @ mlvljr не работает, вот ссылка на страницу Google Книг: books.google.co.in/…
balajeerc
@balajeerc Спасибо (я также исправил ссылку, поэтому она указывает на размещенную в Springer версию того же pdf) :)
mlvljr
1

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

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;

в отличие от

Record r = cache.get(i++, false);
BoBaH
источник
Но do_not_create = falseозначает ли «передать falseкак do_not_createаргумент, чтобы он был создан» или «передать falseкак do_createаргумент, чтобы он не был создан»? На языке, где вы можете использовать имена аргументов, я бы предпочел cache.get (key:i, create: false); i += 1;.
PJTraill
1

Возможно, поможет ответ, иллюстрирующий обратное (плюс это повод, чтобы получить здесь XKCD ).

альтернативный текст

Хороший код

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

Примеры включают

  • Apache Commons
  • Весенние рамки
  • Hibernate Framework
Гэри Роу
источник
1

Я просто пойду с "ремонтопригодным"

Весь код должен быть сохранен: нет необходимости делать эту задачу более сложной, чем необходимо

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

ГБН
источник
1

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

  • Как организован проект? Организованы ли чистые исходные файлы и могу ли я найти код без особых усилий?
  • Как организован код? Четко ли документировано, что делает код в файле, например, с помощью заголовка файла или с использованием каждого класса, находящегося в его собственном файле? Есть ли в файле функции, которые больше не используются в приложении?
  • Как организованы функции? Существует ли четкая схема, где объявляются переменные, или это довольно случайная схема? Есть ли в коде логический поток, позволяющий избежать ненужных структур управления? Все ли четко документировано, когда код самодокументируется там, где это необходимо, а комментарии четко выражают, почему и / или как код выполняет?

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

rjzii
источник
1

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

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

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

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

Так что да, читабельность важна для хорошего кода. Я знаю адагиум Уве Лиггиса: мышление болит, а компьютеры дешевы. Но в моей области (статистическая геномика) время вычислений в неделю и использование памяти более 40 Гб не считаются ненормальными. Так что улучшение в два раза быстрее и вдвое меньше памяти стоит намного больше, чем этот дополнительный бит читаемости.

Йорис Мейс
источник
Нет правил / правил без исключения
user2664856
1
Позвольте мне не согласиться с вашим несогласием: вы говорите, что в вашем поле скорость очень важна, и говорите, что она важнее, чем удобочитаемость. Я не согласен, вы должны стремиться использовать правильный баланс. Если скорость не требуется, например, для интерфейса высокого уровня, вы можете предпочесть что-то простое в обслуживании, если скорость нужна, то я согласен с вами. Вместо жестких правил лучше использовать здравый смысл, и вам все равно следует избегать преждевременной оптимизации.
BlueTrin
@BlueTrin Почему бы не скомпилировать этот исходный код hi-perf и не задокументировать, что там происходит (прямо в комментариях)?
mlvljr
1

Что касается меня ... Я знаю, что пишу хороший код, когда появляется коллега, который работает над другим проектом и может подключиться и понять, что я делаю, без прохождения каждого блока кода. и показывая, что он делает.
Вместо того чтобы сказать: «Подожди минутку, что ?!» Он говорит: «О, хорошо, я вижу, что ты там сделал».

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

chiurox
источник
1

Есть много функций «хорошего» кода, но наиболее важными, IMHO, являются удобочитаемость и удобство обслуживания.

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

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

cjmUK
источник