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

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

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

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

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

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

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

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

( оригинал )

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

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

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

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

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

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

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

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

Код, который

1. без ошибок

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

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

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

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

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

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

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

Источник: MSDN

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

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

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

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

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

в отличие от

Record r = cache.get(i++, false);

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

Хороший код

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

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

• Apache Commons
• Весенние рамки
• Hibernate Framework

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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