Metalab이나 PSA, CPAN과 같은 사이트를 유지하기위해 필요한 작업량이 증가함에 따라, (수작업이 아니라) 프로그램을 이용하여 관리작업의 일부 또는 전부를 처리하려는 경향이 늘어 나고 있다. 이러한 상황에서 컴퓨터가 이해하고 해석할 수 있는 규칙적인 형태로 프로젝트와 압축파일의 이름을 작성하는 것이 매우 중요하게 되었다.
압축 파일이 알파벳 소문자와 숫자로 이루어진 접두사(prefix), 이음선(dash) 그리고 버전 번호, 확장자(extension)와 다른 접미사로 되어 있는 GNU 형의 이름을 가지고 있다면 모든 이에게 도움이 될 것이다. version 1, release 2, level 3 인 `foobar'라는 프로젝트가 있다고 가정해보자. 만약 그것이 압축 파일의 한 부분(아마도 소스일 것이다)이라면 압축파일의 이름은 다음과 같을 것이다.
The source archive
LSM 파일(Metalab에 제출한다고 가정하자)
제발 다음과 같이 쓰지 마시오
이 파일은 버전번호가 없는 'foobar123' 프로젝트의 압축파일로 여길 것이다.
이 파일은 `foobar1'프로젝트의 버전 2.3인 압축파일로 여길 것이다.
이 파일은 'foovar-v1'프로젝트로 여길 것이다.
밑줄은 읽고, 쓰고, 기억하기가 어렵다.
당신이 바보(marketing weenie)처럼 보이고 싶은 것이 아닌 한, 이것 또한 말하고, 입력하고, 기억하기 힘들다.
소스와 바이너리 또는 다른 종류의 바이너리를 구분하거나 파일 이름에 제작 옵션을 표현하려면 다음과 같이, 버전번호 뒤에 오는 파일 확장자(extension)로 설명해라.
소스
형식을 알수 없는 바이너리
ELF 바이너리
static link가 된 ELF 바이너리
SPARC 바이너리
제발 `foobar-ELF-1.2.3.tar.gz'와 같이 사용하지 마라. 왜냐하면 프로그램은�(`-ELF'와 같은) 삽입사(infix)를 이해하지 못하기 때문이다. 일반적으로 바람직한 이름의 형태는 다음과 같은 순서로 되어 있다.
프로젝트 접두사(prefix)
이음선(-)
버전 번호
마침표(.)
"src" or "bin" (선택사항)
마침표(.) 또는 이음선(-) (마침표를 선호한다)
바이너리 형식과 옵션들 (선택사항)
압축 확장자(extensions)
몇몇 프로젝트와 그룹들은 위에서 언급한 규칙과 호환성이 없으면서도 잘 정의된 이름과 버전번호를 가지고 있는 경우가 있다. 예를 들어, 일반적으로 아파치의 모듈들은 "mod_foo"와 같은 형태의 이름을 가진다. 그리고 자신의 버전번호와, 함께 사용되는 아파치의 버전번호를 모두 가진다. 유사하게, Perl 모듈은 버전번호로 소수점을 사용한다. (예. 1.3.3 대신에 1.303을 보게 될 것이다.) 그러므로 "Foo-Bar-1.303.tar.gz"는 1.303버전의 모듈 Foo::Bar를 의미한다.( 그런데, Perl이 이러한 명명 법을 사용하기 시작한 것은 1999년부터이다.) 전문개발자나 전문가그룹이 사용하는 관례는 존중해주어야 한다. 그러나 일반적으로는 아래의 가이드라인을 따르면 된다.
접두사는 모든 프로젝트 파일이 공유해야하고, 읽고 입력하고 기억하기 쉬워야 한다. 그러므로 밑줄은 사용하지 마라. 그리고 아주 특별한 이유가 없다면 대문자로 시작하거나 중간에 대문자를 사용하지 마라. 이러한 것들은 눈으로 자연스럽게 읽는 것을 방해하고, 바보가 영리해 보이려는 것처럼 보인다. 접두사가 고유한 것이 아니라면 그것과 같은 이름의 접두사를 가진 프로젝트를 운영하는 사람들을 혼란스럽게 만들 것이다. 그래서 맨 처음 발표하기 전에 이름이 중복되는지 확인해 보라. 중복을 확인하기 좋은 두 곳은 index file of Metalab과 Freshmeat(부록)이다. 또, 검사하기에 좋은 곳은 SourceForge이다. 이들 사이트에서 검색을 해 보라.