Я составляю правила программирования для моей команды: каковы ваши? - PullRequest
44 голосов
/ 05 февраля 2009

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

Для этого я хотел создать список вещей, которые:

  • лучшая практика,
  • лучшая мысль,
  • лучший подход ...

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

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

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

Начну с первого.

СУХОЙ - Не повторяйся - В коде, комментариях или документации.

Ответы [ 65 ]

52 голосов
/ 05 февраля 2009

Всегда оставляйте код немного лучше, чем когда вы его нашли.

51 голосов
/ 05 февраля 2009

Код не существует, пока не введен в систему управления версиями .

35 голосов
/ 05 февраля 2009

Не бойтесь признать «я не знаю» и спросить.

10 минут с просьбой кого-нибудь сэкономить, потянув за волосы!

32 голосов
/ 05 февраля 2009

ПОЦЕЛУЙ - Делай это просто, глупо.
Выберите самое простое решение, которое работает .
Не усложняйте вещи до того, как они станут необходимыми.
То, что все остальные используют какую-то сложную среду для решения своей проблемы, вовсе не означает, что вы должны это делать.

32 голосов
/ 05 февраля 2009

Не изобретать велосипед

Если должно быть функцией для него в основной библиотеке - вероятно, есть.

29 голосов
/ 05 февраля 2009

Ремонтопригодность важна.

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

27 голосов
/ 05 февраля 2009

Кто-то еще не исправит это.

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

26 голосов
/ 05 февраля 2009

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

«Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла».
- Дональд Кнут

24 голосов
/ 05 февраля 2009

Как тяжело это может быть?
Не позволяйте любой проблеме запугать вас.

23 голосов
/ 05 февраля 2009

Не собирай требования - копай их

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

через Прагматичный программист

...