Hi Bruno, Bruno Haible <[EMAIL PROTECTED]> wrote: >> 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
It is not confusing to me that the group_member function has the following corresponding files in gnulib: m4/group-member.m4 lib/group-member.c lib/group-member.h modules/group-member And what about long-options.c, close-stream.c, copy-file.c, *-safer.c, full-read.c full-write.c, safe-*.c, save-cwd.c, etc. I've made an effort to name files after their functions, but with the s/_/-/g substitution. Do you find those confusing? FWIW, the *-*.[ch] files outnumber the *_*.h ones 138 to 93, in spite of 32 of the latter group matching *_.h. The vast majority of the underscore-adorned files are relatively recent additions. I find the "-" to be just as readable as "_", and easier to type. It's not hard to make the association. >> 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. Sure, if you can get a rename into glibc, I prefer getopt-internal.h, too. >> 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: You held out glibc as a model, with this comment: > The glibc sources contain more files with an underscore (3288) than files > with a dash (2270). My point is that when it comes to adhering to GNU standards, glibc is not always exemplary.
