Hacker News Reader

Comment by tptacek | Hacker News Reader

I honestly am not sure I follow what your concern is with that line of code. list.New() looks extremely clean to me.

You frequently have packages that are named after generic nouns, like time, host, file etc. There are many contexts where this same generic name makes for the best variable name: clear, short, and easy to type:

  func ReadFile(filename String) {
    file := file.Open(filename)
  }

In Go you have to invent a new name, so invariably you will see a lot of:

  theFile := file.Open(filename)
  aFile := file.Open(filename)
  readFile := file.Open(filename)

depending on who wrote the code.

Unless you're also frustrated by not being able to write `int int = 3` in C/C++/C#/Java/most other languages, I don't see the point of your concern.

    f = file.open("a.txt")
    out_file = file.open("b.txt", file.WRITE)

You can write that in C though.

    typedef int foo;

    foo main() {
        foo foo = 0;
        return foo;
    }

You can do the same thing in Golang by renaming the import that clashes with your preferred variable name. Nobody does it, though, because it's not worth the trouble.

In the C# language we refer to this as the 'Color Color problem'. You have some enum or type Color and then a member of an object which you, quite obviously, want to name 'Color'. It's so annoying for the programmer to work around this that we define special exceptions in naming rules so the programmer can do what they want.

the only place where I constantly find this annoying is the url package. url := oh wait, shit, already imported that.

a couple of times I just changed the name of the import, as you sometimes do in Python:

import (

  urllib "net/url"

)

url := urllib.QueryEscape(...)

tada!

I've hit this a few times in Python and it bugged me like crazy. But then I grew up and dealt with it.

Reply on news.ycombinator.com