Naming style inconsistencies in the os package

[ProbablyAdam]

Effective Go says that "...the convention in Go is to use MixedCaps or mixedCaps rather than underscores to write multiword names. For almost every other package this holds true, but I'm puzzled as to why the os package seems to deviate. Here are a few examples:

os.Stdout (not os.StdOut)
os.Getenv (not os.GetEnv)
os.Getgroups (not os.GetGroups)
os.FileInfo.Atime_ns (not os.FileInfo.ATimeNS)

The only reason I'm being picky is that the os package is the only one where I occasionaly need to use godoc in order to remember the names.

If this were any other language I wouldn't bring this up, but I've noticed that wrinkles have been ironed out of other packages with the help of gofix.

Has this been discussed before?

[Brad Fitzpatrick]

The os package is an old package, developed before the naming convention or upper case export rule was settled upon.  So once the capitalization rule came about, everything in package os was capitalized, afaik, but the rest of the convention hadn't been decided.

Also, things that are typical Unix / C names are considered one word, hence os.Getenv instead of os.GetEnv.  But os.Getenverror is weird and should probably be os.GetenvError, similar to os.MkdirAll.

I believe people have mentioned wanting to do a clean-up pass at some point in the future.  Personally I hope it's sooner than later.

[peterGo]

ProbablyAdam,

Yes.

Issue 1187: os: inconsistent casing in names
http://code.google.com/p/go/issues/detail?id=1187

Peter

On Jun 21, 10:20 am, ProbablyAdam <probablya...@gmail.com> wrote:
> Effective Go says that "...the convention in Go is to use MixedCaps or
> mixedCaps rather than underscores to write multiword names. For almost every
> other package this holds true, but I'm puzzled as to why the os package
> seems to deviate. Here are a few examples:
>

> os.Stdout *(not os.StdOut)*
> os.Getenv *(not os.GetEnv)*
> os.Getgroups *(not os.GetGroups)*
> os.FileInfo.Atime_ns *(not os.FileInfo.ATimeNS)*

[ProbablyAdam]

I notice that the issue is 6 months old. I just wonder if it has a better chance of getting resolved now that the gofix tool is available?

[peterGo]

ProbablyAdam,

Issue 1187 is marked as long term and low priority. Functions can be
renamed with a gofmt rewrite rule.

Contributions are always welcome.

Contributing
http://golang.org/doc/contrib.html

Peter

[Rob 'Commander' Pike]

There are inconsistencies but this is the key point. It should be Stdout not StdOut, because that name is coming from the underlying system. Similarly it's Fprintf not FPrintf or FPrintF because that is a very familiar name. These names are coming into Go, not being created there, and the initial cap is the admission fee.

-rob

[ProbablyAdam]

How well would changes to this be received?

Amongst others I was thinking of changes similar to this:

s/Clearenv/ClearEnv/
s/Getenv/Env/
s/Getgid/GID/
s/Getgroups/Groups/
s/Getpagesize/PageSize/
s/Getpid/PID/
s/Getuid/UID/
s/Setenv/SetEnv/
s/Readdir/ReadDir/
s/Readdirnames/ReadDirNames/

Note the use of XYZ not GetXYZ, as per the description in Effective Go: "...the getter method should be called Owner (upper case, exported), not GetOwner".

I should add that I know that some of the names are mappings to their C equivalents, but this isn't C.

[Rob 'Commander' Pike]

No, but they're names from a C interface and most should be left alone. It's just gratuitous to change Getpid to PID.

-rob

[ProbablyAdam]

I'll concede that removing "Get" from the function names may not be the best idea. If you did it to one you'd need to do it to all for consistency, and os.WD doesn't seem too appealing.

How about introducing some camel casing to the names?

The syscall package has an understandable link to C, but is it required for the os package as well?

[Russ Cox]

> How about introducing some camel casing to the names?

No.

Did you read Rob's first reply?

Russ