New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: os: fix inconsistent casing in names #1187

Open
niemeyer opened this Issue Oct 10, 2010 · 12 comments

Comments

Projects
None yet
6 participants
@niemeyer
Contributor

niemeyer commented Oct 10, 2010

Is there any sort of rule about the casing of functions used in the "os"
package?  Looking through, it doesn't sound like it's very easy to recall whether a
given function should be called LikeThat or Likethat.

For instance:

Mkdir
MkdirAll
TempDir
Getenv
ForkExec
Readlink
ReadAt
Readdir

It feels very ad-hoc, and hard to recall.
@peterGo

This comment has been minimized.

Contributor

peterGo commented Oct 10, 2010

Comment 1:

It's easy to see what the casing rules are. Mkdir, Getenv, Readlink, and Readdir os
package names are all equivalent to corresponding Linux (and other Unix-style OSs)
lower-case function names with the first character capitalized so that the function
names are exported. MkdirAll, TempDir, ForkExec, and ReadAt have no corresponding OS
functions and use Go standard camel-case names with the first character capitalized so
that the function names are exported.
@niemeyer

This comment has been minimized.

Contributor

niemeyer commented Oct 10, 2010

Comment 2:

Not really (e.g. Readdirnames).
Then, even if that was the case, it'd be much better to have it internally consistent
than having a rule which includes knowing what another standard looks like.
@peterGo

This comment has been minimized.

Contributor

peterGo commented Oct 10, 2010

Comment 3:

The Go Nuts mailing list is for Go language questions and discussions.
http://groups.google.com/group/golang-nuts
These has already been a discussion of these issues: FunctionName caseinconsistencies.
http://groups.google.com/group/golang-nuts/browse_thread/thread/dc52b51b4f007d50/
@niemeyer

This comment has been minimized.

Contributor

niemeyer commented Oct 10, 2010

Comment 4:

Yes, and the issue tracker is to report issues? Feels like both are being used the way
they should.  Also, the message from Russ which you point out seems to agree with the
problem I report:
"Names like Readdirnames, which are actual words, might be worth revisiting at some
point."
So, here is an issue to track this.
@rsc

This comment has been minimized.

Contributor

rsc commented Oct 11, 2010

Comment 5:

Labels changed: added priority-low, removed priority-medium.

Status changed to LongTerm.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 9, 2011

Comment 6:

Labels changed: added priority-someday, removed priority-low.

@gopherbot

This comment has been minimized.

gopherbot commented Jul 4, 2012

Comment 7 by elimisteve:

Agreed. 'strings.SplitN' and 'random.Intn' come to mind as well.
@gopherbot

This comment has been minimized.

gopherbot commented Jul 4, 2012

Comment 8 by elimisteve:

Agreed. And regarding consistency of casing in general, 'strings.SplitN' and
'random.Intn' come to mind as well.
@rsc

This comment has been minimized.

Contributor

rsc commented Jul 30, 2013

Comment 9:

Labels changed: added go2.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 10:

Labels changed: added repo-main.

@rsc

This comment has been minimized.

Contributor

rsc commented Mar 3, 2014

Comment 11:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc changed the title from os: inconsistent casing in names to proposal: os: inconsistent casing in names Jun 17, 2017

@rsc rsc changed the title from proposal: os: inconsistent casing in names to proposal: os: fix inconsistent casing in names Jun 17, 2017

@bankole7782

This comment has been minimized.

bankole7782 commented Apr 24, 2018

I think this is manageable. It could lead to a lot of hard to do program rewrites.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment