Golang Naming Conventions

Why does Go use meaningless, hyper-truncated names for variables, functions, statements and packages like it’s 1970 and source code size is limited by storage space and compiler speed?


Stewart Griffin on 2012-06-19 at 12:45 said:

Perhaps the guys writing it have RSI and are conscious of every single keystroke. Or perhaps they just agree with the fashionable idea that shorter programs are better. Paul Graham did a lot to push this trend with his ‘Take the Arc challenge’:

...I worked on things that would make programs shorter. Why would I do that? Because making programs short is what high level languages are for. It may not be 100% accurate to say the power of a programming language is in inverse proportion to the length of programs written in it, but it's damned close...

Whether influence by Paul Graham or not the Go team does seem to be focused on minimalism and brevity.

Also, if you use the language then fmt.Println is no harder than format.Println as you get used to the standard package names fairly quickly as you are always using them. Do you have a more pernicious example? It is only in the last few weeks that I started playing with Go and so might be missing something.

Ant on 2012-06-19 at 15:23 said:

I’ve spent the last 8 months or so engrossed in the famously verbose Objective-C, and I’ve been spoiled by its descriptiveness. Here’s how you create a string from an integer in objc:

int i = 123;
NSString *s = [NSString stringWithFormat:@“%d”, i];

As long as you’re familiar with objc’s syntax, the above is obvious despite the appallingly named variables. There’s no need to memorise the NSString API to know that “stringWithFormat” will produce a new NSString object from its list of arguments.

Now contrast that with the Go version:

i := 123
s := fmt.Sprintf(“%d”, i);

Even if you know Go’s syntax, the meaning of “Sprintf” isn’t obvious unless you’ve memorised it or have the documentation open. What’s worse is that the meaningless variable names (which seem to be enormously popular in Go, at least judging from all of the official docs and tutorials) make it difficult to guess at what’s going on from the context.

Sprintf isn’t the worst name in the “fmt” package. It returns a string, so one would assume that the name would expand out to “print to string”. Makes sense. Now figure out why “Fprintf” is so called when it sends its output to a Writer. Why, it’s because the “fprintf()” function in C sent its output to a file. “Print to file”, see? In order to understand the names of functions in Go you’ll need to know Go and C. It’s a new language immediately laden down with 40 years of accumulated cruft for no obvious reason. Why not call it “WPrintf” instead? Or “PrintToWriter”? Or support overloading in the language and call it “Print” for all scenarios and pass a Writer as the first argument?

I agree that shorter programs are better, but I think the way to achieve that is by making the language more powerful (consider Python’s list comprehensions, Go’s slices or C#’s lambdas) rather than ripping out all of your keyboard’s vowels and mkng th nms f vrythng shrtr.

I don’t understand why the language designers copied abbreviated names from C (which had severe hardware limitations influencing its naming conventions) when they put so much thought into areas such as the order of variable declarations (“i * int” instead of “int * i” so that declarations can be read meaningfully from left to right).

Stewart Griffin on 2012-06-20 at 09:29 said:

It’s a new language immediately laden down with 40 years of accumulated cruft for no obvious reason

Yeah, I see what you are saying. Certainly Fprintf does not really work as a name in this version.

I guess they are framing it the other way: it is a new language, but with the benefit of building on 40 years of experience and cultural knowledge from the C world. It does give it a certain familiarity to the low-level guys they are targeting with Go, which is meant to be a systems language for the future (or something like that). Whether they have this right and are going to be familiar in a likeable way, such as Java sticking with traditional C syntax, or just annoying and obscure is a judgement call that I have no idea about.

Also, it could just be that those guys have been writing C so long (Pike, Thompson, etc) that those names just look obvious and make sense to them now, even when they don’t. Obviously, that would not be the best reason to go in their direction.

Ant on 2012-06-20 at 14:31 said:

Retaining some level of familiarity for C programmers was the only valid reason I could come up with for some of the choices, and it explains why the designers spend so much time comparing it with C:


However, I think the conversation with old-timer C programmers would go something like this:

"We've written a new systems programming language!"
"We've got one of the original UNIX guys onboard!"
"It fixes all sorts of design problems in C!"
"It has a garbage collector!"

Meanwhile, a similar conversation with a young whippersnapper who suddenly needs a systems programming language, but has no C experience, would go like this:

"We've written a new systems programming language!"
"It has a garbage collector!"
"Its naming scheme assumes you've been using C for 10 years!"

Stewart Griffin on 2012-06-20 at 14:43 said:

"It has a garbage collector!" *"Blasphemy!"*

Yes! When I heard systems language and garbage collector in the same description I thought they were going to have a tough sell. I guess they are just making the language they want: C, tidied up with GC and concurrency support and not worrying about much else.

Flake on 2012-09-14 at 05:03 said:

Does the problem go far beyond the “fmt” package? Because I always felt that fmt was designed for C fans, as in it was a way to do formatting intentionally C style, therefore C naming conventions would make sense, no?

Ant on 2012-09-14 at 16:09 said:

The “fmt” package is probably the worst offender for function names, but terse variable names are used everywhere. Here’s an example:

func Verify(pub *PublicKey, hash []byte, r, s *big.Int) bool

Without looking up the dsa package, can you tell what “r” and “s” represent?

func (s *Stmt) Close() error

Without looking up the database package, can you tell what “s” is? Or what “Stmt” expands to? For bonus points, figure out exactly how many milliseconds you save typing “Stmt” over (presumably) “Statement”.

func ParseExpr(x string) (ast.Expr, error)

In this one, “x” is presumably an expression, but “ast.Expr”? It’s an expression from the Go language syntax tree package. But why “ast”? What does the “a” stand for?

func Atoi(s string) (i int, err error)

More C cruft in the “strconv” package.