Независимо от подхода к конфигурации, не следует задавать пользователю вопросы по конфигурации системы на этапе компиляции. Пользователь, устанавливающий пакет, не знает ответов на эти вопросы, и такой подход обречен с самого начала. Программа должна быть способна определить любые необходимые ей данные во время компиляции или установки.
Однако утилиту autoconf нельзя рассматривать как одобрение кнопочных конструкций. Если вообще возможно, при программировании необходимо придерживаться стандартов, подобных POSIX, и воздерживаться от опроса системы для получения конфигурационной информации. Рекомендуется сохранять минимальное число ifdefs-директив, а еще лучше — не иметь их вообще.
19.2.3.3. Тестируйте код перед выпуском версии
Хороший тестовый комплект позволяет коллективу легко выполнять возвратные тесты перед выпуском новых версий. Рекомендуется создавать устойчивую, полезную структуру теста, для того чтобы можно было последовательно добавлять в программу тесты без необходимости обучать разработчиков специфическим сложностям тестового комплекта.
Распространение тестового комплекта позволяет сообществу пользователей проверить свои версии перед отправкой пожеланий группе разработчиков.
Поощряйте разработчиков к использованию широкого многообразия платформ в качестве настольных и тестовых машин, для того чтобы непрерывная проверка кода на предмет дефектов переносимости стала частью обычной разработки.
Хорошая практика, подкрепляющая уверенность в коде, заключается в поставке кода с тестовым комплектом, который используется разработчиком и который можно запустить с помощью команды make test.
19.2.3.4. Выполняйте контроль ошибок в коде перед выпуском версии
Под "контролем ошибок" (sanity check) здесь подразумевается использование всех доступных инструментов, обладающих приемлемой способностью к обнаружению ошибок, которые человек склонен пропускать. Чем больше таких ошибок обнаружат данные инструменты, тем меньше пользователям и самому разработчику придется с ними бороться.
При написании программ на C/C++ с использованием GCC рекомендуется выполнять тестовую компиляцию с параметром -Wall и устранять все ошибки перед каждым выходом новой версии. Кроме того, стоит компилировать код всеми доступными компиляторами — разные компиляторы часто обнаруживают различные проблемы. В частности, скомпилируйте программу на машине с действительно 64-битовой архитектурой. Базовые типы данных могут изменяться на 64-битовых машинах, и поэтому в них часто обнаруживаются новые проблемы. Найдите систему Unix-поставщика и запустите утилиту lint для проверки программы.
Используйте инструменты, которые ищут утечки памяти и другие ошибки времени выполнения. Программы Electric Fence и Valgrind — хорошие инструменты, доступные в виде открытого исходного кода.
Для Python-проектов полезным инструментом проверки может оказаться программа PyChecker <http://sourceforge.net/projects/pychecker>. Она часто обнаруживает нетривиальные ошибки.
При написании программ на Perl проверять код следует с помощью ключа -с (и возможно -T, если он применим). Используйте ключ -w и конструкции "use strict". (Дальнейшую информацию можно найти в документации на Perl.)
19.2.3.5. Проверяйте орфографию в документации и README-файлах перед выпуском версии
Проверяйте грамотность документации, README-файлов и сообщений об ошибках в программе. Сырой код, т.е. код, который вызывает появление сообщений об ошибках при компиляции и имеет орфографические ошибки в текстах README-файлов и предупреждений, приводит пользователей к мысли, что проектирование данной программы также случайно и бессистемно.
19.2.3.6. Рекомендованные практические приемы переносимости кода C/C++
При написании программ на С используйте полные ANSI-функции. В частности, используйте прототипы функций, которые помогают выявить несовместимость между модулями. Старые компиляторы в стиле K&R — древняя история.
Не полагайтесь на специфические для некоторых компиляторов функции, такие как GCC-параметр -pipe или вложенные функции. Они впоследствии повлияют на чужие порты в не-Linux и He-GCC-системе.
Необходимый для обеспечения переносимости код должен быть изолирован в отдельной области и отдельном наборе исходных файлов (например, в подкаталоге os). Компилятор, библиотека и интерфейсы операционной системы с проблемами переносимости должны быть абстрагированы в файлы данного каталога.