bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: underscores in gnulib file names


From: Jim Meyering
Subject: Re: underscores in gnulib file names
Date: Sat, 08 Sep 2007 15:02:20 +0200

Hi Bruno,

Bruno Haible <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]