Чеклист для хорошего программирования

Этот чеклист должен помочь вам писать высококачественные программы.

Рафаэль Финкель, 17.08.2005

  • Идентификаторы: убедитесь, что все ваши идентификаторы значимы.
  • Однобуквенные идентификаторы почти никогда не имеют смысла.
  • Такие имена, как flag и temp, редко бывают значимыми. Вместо flag рассмотрите возможность присвоения имени логическому условию, которое он проверяет, например valueFound.
  • Рассмотрим идентификаторы, состоящие из нескольких слов, например nameIndex. Длинные идентификаторы (в пределах разумного) обычно хорошо читаются.
  • Голые литералы: избегайте чисел, отличных от 0 и 1, и строк, отличных от “”, в вашей программе, кроме случаев, когда вы определяете константы.
  • Не используйте буквальное целое число в качестве границы массива.
  • Не используйте буквальное целое число в качестве параметра запуска, например тайм-аут или номер порта.
  • Не используйте буквальные целые числа для выбора пунктов меню.
  • Не используйте буквальное целое число для измерения размера строки или некоторых данных; используйте sizeof () и strlen () в C и C ++ и .length () и .size в Java.
  • Не используйте буквальную строку для имени файла. Однако вы можете выводить буквальные строки.
  • Не используйте буквальное целое число для индексации массива, содержащего разнородные данные.
  • Не объявляйте идентификатор с именем, обозначающим буквальное значение, например «тридцать».
  • Модуляризация: программа строится из взаимодействующих компонентов.                                                  
  • Не помещайте весь свой код в процедуру main ().
  • На самом деле, не заставляйте рутину делать слишком много работы. Если он длиннее примерно 50 строк, возможно, он слишком длинный
  • Если вы дублируете код несколько раз, подумайте, будет ли лучше работать цикл или, возможно, подпрограмма.
  • Если вы обнаружите, что делаете очень глубокие отступы, скорее всего, вы не используете подпрограммы, когда должны.
  • Не изобретайте заново библиотечные процедуры (если этого не требует ваше задание). Посмотрите руководства, чтобы узнать, например, о sprintf () и atoi ().
  • Используйте файлы заголовков в C и C ++ (файлы заголовков имеют имена, оканчивающиеся .h), чтобы определить все константы, необходимые для нескольких файлов, и объявить все подпрограммы, экспортируемые между файлами. Но не помещайте тело подпрограмм в файлы заголовков (за редким исключением встроенных подпрограмм).
  • Форматирование: Ваша программа должна легко читаться.

1. Посмотрите на http://geosoft.no/development/javastyle.html четкие предложения по форматированию и другим вопросам, связанным с презентацией. Эта ссылка специально предназначена для Java, но имеет ценность и для других языков.

2. Постарайтесь ограничить все ваши строки 80 символами; многие люди просматривают код в окнах с 80 столбцами по историческим причинам.

3. Не используйте для отступа одновременно табуляции и пробелы, потому что не все текстовые редакторы обрабатывают табуляцию как ровно 8 пробелов

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

5. Не помещайте в программу много пустых строк. Достаточно одной пустой строки между подпрограммами.

6. Различные операционные системы по-разному завершают линии. Если вы перемещаетесь между Win32 (который использует \ r \ n), Unix (который использует \ n) и MacOS (который использует \ r), переформатируйте файл, чтобы использовать согласованный метод завершения.

7. Не устанавливайте исполняемый бит (Unix) в исходных файлах.

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

1. Не используйте последовательность операторов if, у которых нет else, если может соответствовать только один; используйте else if.

2. Если вы хотите классифицировать ввод текста, не перечисляйте возможные первые символы.

3. Используйте операторы сдвига вместо умножения для построения битовых комбинаций.

4. В операторе switch всегда проверяйте регистр по умолчанию. Точно так же в последовательности операторов if-then-else используйте последний else.

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

6. Логические значения всегда должны использовать логический тип в Java, bool в C ++ и целые числа 0/1 в C. Не используйте символы t и f и не используйте -1 и 1.

7. Если возможно, используйте циклы для инициализации структур данных.

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

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

10.  Если вы изменяете данные с помощью htonl () или аналогичной процедуры перед передачей по сети, не изменяйте данные на месте. Создайте вторую структуру данных.

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

12.  Программы Shell, Perl и Python должны иметь свои #! строка как первая строка файла; в противном случае строка является просто комментарием.

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

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

1. Для C и C ++ используйте флаг -Wall.

2. Для Java используйте -Xlint: all -deprecation и используйте программу pmd, чтобы получить предложения по лучшему стилю.

3. Для Python используйте -t -W all.

4. Для Perl используйте флаг -w и укажите use strict. Скрипты Cgi-bin также должны иметь флаг -T.

  • Утилита make: используйте ее и используйте ее правильно.

1. Makefile всегда должен иметь “чистый” рецепт, который должен удалять все файлы, которые могут быть реконструированы другими рецептами в Makefile, включая объектные и исполняемые файлы.

2. Если ваш проект имеет несколько исходных файлов, Makefile должен генерировать объектные (.o) файлы по мере необходимости и связывать их вместе.

3. Файл Makefile должен быть написан таким образом, чтобы, если вы запускаете make дважды подряд, при втором запуске перекомпиляция не производится.

4. Каждый рецепт должен создавать файл, указанный в его цели.

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

6. Научитесь использовать правила для таких целей, как .c.o, чтобы избежать повторяющихся make-файлов.

7. Если у вас есть только один исходный файл C или C ++, исполняемый файл должен иметь то же имя (без расширения .c или .cpp).

8. Убедитесь, что вы указали все файлы .h в качестве предварительных требований там, где они необходимы. Подумайте об использовании makedepend для создания списка необходимых компонентов.

  • Документация: это не только для грейдера. Это также поможет вам при написании программы!

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

2. Напишите внешнюю документацию: как скомпилировать и запустить программу и для чего она предназначена? Внешняя документация обычно находится в отдельном файле README; для небольших проектов это может быть комментарий в едином исходном файле.

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

4. Проверьте всю свою программу и документацию на наличие орфографических ошибок. Невежливо сдавать работы с ошибками и свидетельствует о невнимании к деталям.

5. Проверьте всю свою документацию (и выходные сообщения) на наличие грамматических ошибок.

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

Оригинальная статья

This article was translated by one of the writers from paper writing services review website https://bestessayservicesradar.com/