Hi Jim,
> It's not that bizarre, and it's been present in the GNU culture
> for a very long time. "-" is easier to type than "_", since
> the former is a single key-press and the latter usually requires two.
> Perhaps the fact that it is not as well known as it should be is
> the reason there are so many exceptions.
Another reason is that - especially in gnulib - file names are often named
after a C function. When a source file provides a function named
'pagealign_alloc', it would be confusing to call the files that implement
it anything else then
modules/pagealign_alloc
lib/pagealign_alloc.h
lib/pagealign_alloc.c
m4/pagealign_alloc.m4
> Obviously I haven't told
> everyone: getopt_int.h sounds like something from libc, so no point
> in bothering, there. The foo_.h names are a little different. There,
> the "_" is less of a word separator than a suffix, so it doesn't seem
> to break the rules as flagrantly.
If there's a rename to do, I'm all for choosing self-descriptive names.
- getopt_int.h sound like it deals with options of type 'int'. A
better name would be getopt-internal.h.
- The getopt_.h naming does not make it clear that the file is preprocessed.
I would see it as an improvement to rename it to getopt.in.h or
something else that makes allusion to the getopt_.h -> getopt.h
substitution step.
> glibc is very nice software, but it is not a model
> of adherence to GNU or portability standards.
Portability is not an argument for avoiding the underscore:
- Even the oldest platforms (DOS, Windows 3.1, VMS [1], SVR2) support
filenames with dashes and with underscores.
- The 'pathchk' program does not print warnings for filenames with
underscores.
Really, the issue is not about portability. It is about the personal
preference of a group of developers (the Emacs developers) to use dashes
instead of underscores.
Bruno
[1] http://search.cpan.org/~clane/VMS-FileUtils_0.014/safename/safename.pm
