Comment by hashrate | Hacker News Reader

Comment by hashrate | Hacker News Reader

Parent Full thread

This is suppose to be funny , unfortunately this is the sad reality of what you'll find in 90% of Enterprise / Startups environment as well as THE majority of open source repositories of popular open source projects.

I've noticed this especially true for JavaScript and Go.

In JavaScript , because the language is still evolving and there is no real standard about how to architect code with this language unless you are using a entire "platform" like Angular / Vue / React witch will highly influence your coding style.

In Go because Go developers are performances obsessed , coming from C/C++ background and do believe that naming their variable with one letter will save 1GB of memory allocation , 1000 CPU Cycles and make their code "Clear and Concise"

Ultimately , because there is very little standard in this industry in terms of code governance and a large percentage of projects are outsourced to other companies , we end up with what is described in this repository.

I find Go code ideal for maintainability, with the "one way to do things" philosophy. Developers often don't like Go precisely because it does not allow them to do "clever" things.

Go is also not performance obsessed - else it would not have opted for garbage collection by default.

As far as variable naming goes, Go convention says - the further from its declaration a variable is used, the more explicit and qualified the name should be to disambiguate it. This to me strikes as being eminently sensible.

In Go single letter variables are used when they are short lived (3 or 4 lines) and in this cases I find it way more readable than long names.

It's also perfectly acceptable (and preferred) if the code maps cleanly onto some existing mathematical terminology. 'v' is more readable than 'velocity' in the correct context.

... until it isn't.

The problem is that you get too close to the code you write, and make assumptions about its obviousness that simply aren't true. Far better to be explicit at the cost of a few extra keystrokes.

Yes, single letter variables do have their place. But this place is very limited. Consider these lines in ruby

    data.reject{|e| e.value.nil?}

    data.reject{|element| element.value.nil?}

I would always prefer the first one. My general rule of thumb is: If a variable has the scope of exactly one line, or if it is an incremental counter, use one letter.

I just read it and thought 'e' was an error.

I’ll admit to a few larger funcs where I used one letter variables. It always starts with me thinking it will be a three-line routine, then It turns into a 30 line monstrosity that I don’t realize until I get a code review comment like “wtf is ‘zz = z’ about?”

Agree. But as a postscript this is really funny and well written.

Reply on news.ycombinator.com