Я составляю правила программирования для моей команды: каковы ваши? - PullRequest
Новая
       125

Я составляю правила программирования для моей команды: каковы ваши?

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

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

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

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

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

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

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

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

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

Ответы [ 65 ]

1 голос
/ 06 февраля 2009

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

Но не забывайте документировать все равно.

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

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

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

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

0 голосов
/ 08 февраля 2009

Код без юнит-тестов по определению не работает.

Self-пояснительная.

0 голосов
/ 06 февраля 2009

В первый раз никогда не бывает легко. Это будет несложно сделать каждый раз после. Это все равно что пытаться найти короткий путь в первый раз, когда вы едете куда-то. До GPS.

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

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

Я был бы рад поделиться этим. Но это не просто ОДНО правило, это было больше «Руководства по кодированию», чем что-либо еще.

Вот примерный план того, что содержал мой документ: 

        A.      Source Code
           a.   Formatting
           b.   Variable naming
           c.   Error handling
           d.   Logging
           e.   Text Editor
           f.   Scope Declaration
           g.   Comments / Comment blocks
           h.   Documentation
           i.   API/Library Development standards

       B.       Source Control
          a.    Check-in/Check-out
          b.    Version information
          c.    What belongs in Source Control?

А вот пример из раздела А. 

<b><H2>Source Code</H2></b>
<b>Text Editor:</b>

Выбор текстового редактора зависит только от разработчика. Шрифты должны быть с одинарным интервалом, не больше 18 и не меньше 8. Хотя это выбор разработчиков, в верхней части исходного файла должны присутствовать комментарии к коду, указывающие, какой редактор, шрифт, размер шрифта и, если применимо, размер отступа должен присутствовать. См. Комментарии / Блоки комментариев для получения дополнительной информации. 

<b>Tabs:</b>
Вкладки НИКОГДА не должны быть в исходных файлах. Вкладки должны быть заменены пробелами и иметь отступ 4. 
<b>Line Endings:</b>
Окончания строк должны быть в формате CRLF. Большая часть исходного кода {название вашей компании} находится на платформе Windows, поэтому в конце строки должно быть установлено значение CRLF, чтобы его можно было читать в Windows. Окончания строк никогда не должны смешиваться ни в одном исходном файле. 
<b>Line Length:</b>
Длина строки не должна превышать 200 символов для большинства строк. Допустимы очень длинные строки в одном источнике. Определения функций или вызовы функций должны быть разбиты (и задокументированы). (См. Раздел API / Библиотека для получения дополнительной информации.)

Конечно, это то, что сработало для США, вашего MMV, и вам пришлось бы корректировать правила в соответствии со своими стилями кодирования.
0 голосов
/ 06 февраля 2009

Всегда пишите документацию для своего кода! Через полгода вы не вспомните о том, как это работает. Поэтому не пишите код без документации!

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

Некоторые вещи сделаны лучше, чем описано

Не попадайте в спираль спецификации - в какой-то момент вам нужно начать кодирование.

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

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

Не пытайтесь сделать вещи проще, чем они.

Знание того, что вы делаете, предпочтительнее модульных тестов.

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

Зачем вам тратить свою жизнь на методологии проб и ошибок?

0 голосов
/ 10 марта 2009

Люди, которые немного знают о чем-то (процесс / программное обеспечение), являются самыми опасными людьми в мире.

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

  1. Понимание / прохождение кода приложения, которое хорошо, плохо и безобразно . Вы будете лучше понимать, что работает, а что нет.

  2. Поговорите с людьми (ИТ и бизнес) и не бойтесь задавать вопросы. Это работает для вас двумя способами: -

    а) Вы становитесь более доступным, так как кажетесь более человечным, чем просто этот ботаник, который не говорит

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

Страница:
...