Искусство программирования для Unix
Шрифт:
По мере роста нагрузки на кураторов архивов, подобных ibiblio, SourceForge и CPAN, возрастает тенденция к обработке заявок частично или полностью программным путем (вместо полной их проверки вручную).
В связи с этим возрастает важность подчинения имен проектов и архивов обычным шаблонам, которые могут анализироваться и распознаваться программами.
19.2.2.1. Используйте GNU-стиль названий с именной частью и номерами (основной.второстепенный.заплата)
Будет
Хорошая общая форма названия содержит следующие части в указанном порядке.
1. Префикс проекта.
2. Дефис.
3. Номер версии.
4. Точка.
5. "src" или "bin" (не обязательно).
6. Точка или дефис (точка предпочтительнее).
7. Тип бинарных файлов и параметры (не обязательно).
8. Расширения архивирования и компрессии.
Именная часть в данном стиле может содержать дефис или подчеркивание для разделения составляющих слов; в настоящее время использование дефисов предпочтительнее. Хорошей практикой является группировка связанных проектов путем включения в именные части общего префикса, ограниченного дефисом.
Предположим, существует проект, который называется "foobar", основной номер версии (major version) 1, второстепенный номер версии (minor version) или выпуска 2, уровень исправлений (patchlevel) 3. Ниже представлены примеры названий для проекта, содержащего только один архив (предположительно исходный код).
foobar-1.2.3.tar.gz
Архив исходного кода.
foobar.Ism
LSM-файл (для публикации в ibiblio).
Не следует использовать имена, подобные приведенным ниже.
foobar12 3.tar.gz
Многие программы распознают такое имя как архив для проекта, который называется "foobar 123" без номера версии.
foobarl.2.3.tar.gz
Многие программы распознают такое имя как архив для проекта, который называется "foobart" версии 2.3.
foobar-vl.2.3.tar.gz
Многие программы распознают такое имя как проект, который называется "foobar-vl".
lboo_bar-1.2.3.tar.gz
Подчеркивание плохо передается в устной речи, его неудобно вводить и запоминать.
PooBar-1.2.3.tar.gz
Если только разработчик не хочет выглядеть как знаток маркетинга. Такая форма также трудна для устного выражения, ввода и запоминания.
Если необходимо дифференцировать архивы исходного кода и бинарных файлов или различные виды бинарных файлов, либо выразить в имени файла некоторые параметры компиляции, то данную информацию следует интерпретировать как расширение файла, следующее после номера версии. Примеры приведены ниже.
foobar-1.2.3.ere.tar.gz
Исходный код.
foobar-1.2.3.bin.tar.gz
Бинарные файлы без указания типа.
foobar-1.2.3.bin.i3 8
Бинарные файлы для архитектуры i386.
foobar-1.2.3.bin.i386.static.tar.gz
Статически связанные бинарные файлы для архитектуры i386.
foobar-1.2.3.bin.SPARC.tar.gz
Бинарный код для архитектуры SPARC.
Не используйте такие имена, как "foobar-i386-1.2.3.tar.gz", поскольку программы испытывают затруднения с выделением инфиксов типа (например, '4386") из именной части.
Соглашение о различиях основной и второстепенной нумерации версий весьма простое: уровень заплат увеличивается на единицу для исправлений или внесения незначительных функций, второстепенный номер версии — для совместимых новых функций, а основной номер версии увеличивается, когда сделаны несовместимые изменения.
19.2.2.2. По возможности необходимо придерживаться локальных соглашений
В некоторых проектах и сообществах имеются четкие соглашения для имен и номеров версий, которые не обязательно согласуются с приведенными выше рекомендациями. Например, модули Apache, как правило, получают такие имена, как "modfoo", и имеют номер собственной версии и номер версии Apache, с которой они работают. Подобным образом, модули Perl имеют номера версий, которые можно интерпретировать как числа с плавающей точкой (например, можно встретить версию 1.303, а не 1.3.3), а дистрибутивы обычно получают такие имена, как "Foo-Bar-1.303.tar.gz", для версии 1.303 модуля Foo::Bar. (Сам проект Perl, с другой стороны, перешел на использование описанных здесь соглашений в конце 1999 года.)
Ищите и следуйте соглашениям определенных сообществ и разработчиков; для общего использования придерживайтесь описанных выше принципов.
19.2.2.3. Упорно ищите уникальный префикс имени, который легко вводить
Основной префикс должен быть общим для всех файлов проекта, а также должен легко читаться, вводиться и запоминаться, поэтому не следует использовать символ подчеркивания. Также не следует без крайне важной причины использовать прописную букву или две прописные буквы — это вносит путаницу в естественный порядок зрительного поиска и выглядит так, как будто новичок маркетинга пытается показаться умнее.
Два различных проекта, имеющих одинаковые именные части, сбивают людей с толку. Поэтому, прежде чем выпускать первую версию, необходимо проверить имя на предмет конфликтов. Для такой проверки можно использовать индексный файл проекта ibiblio <http://metalab.unc.edu/pub/Linux> и индекс приложений на сайте Freshmeat <http: //www. f reshmeat.net>. Хорошим ресурсом для проверки также является сайт проекта SourceForge <http: //www. sourceforge .net>.
19.2.3. Хорошая практика разработки