3 ms·

I haven't used Go het, but try to keep up to date. One issue I have is that naming conventions seem all over the place. Is there a logic behind the naming of th

I haven't used Go het, but try to keep up to date. One issue I have is that naming conventions seem all over the place. Is there a logic behind the naming of things? For example, function names are sometimes CapitalizedLikeThis, but sometimesLikeThis. This kind of messy inattention to detail makes the language come across as sloppy and unfinished.

kaib 16y ago
This is actually part of the language. Identifiers starting with a capital letter are exported outside the package, the ones with a lower case letter are not.
uriel 16y ago
This is covered in the basic language introduction: names starting with a capital letter are public, names starting in lower case are private. Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better).
- 198d 16y ago
  Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better). Do you mind explaining this statement a little further, specifically related to Python and Ruby. I work with both of those languages and find the naming conventions to be quite clean and respected. The style of the language is not enforced, but you'll certainly be chastised by any serious developer in either language for doing something outside the norm.
  - uriel 16y ago
    The Python stdlib is full of examples of CamelCase, under_score and alltogether. In Ruby just looking at the methods for strings is enough to find this like: "instance_variable_defined?", "rindex", "tr_s", "casecmp", "equal?", "eql?" and more. Yes, it is all lower case, but consistent it is certainly not.
    - lepht 16y ago
      I also find myself wishing that Ruby's destructive (!) and boolean (?) suffixes were either enforced somehow or not used at all. The idea itself is cool, communicating extra context about what the method does or its intended usage, but they're used so inconsistently (even withing the Ruby stdlib) that A) They're unreliable and you need to check the source to find out the behavior anyway and B) It's less predictable whether the method exists with the suffix or without, so you need to either run it and modify your method call if there's an error or check the lib/API docs. This is the sort of thing that makes having an IDE handy for completing method names, which is unfortunate because Ruby is generally very usable without any IDE crutches.
- lobster_johnson 16y ago
  I see. I applaud new ideas, but personally I find Go's choice visually jarring; on the screen it ends up looking like a train wreck: fmt.Printf(colorizeWithAnsi(strings.Replace(s, " ", "/", -1)); It goes from being mere syntax (like Ruby's elegant use of '@' to denote instance variables) to screwing with the names themselves apparently just to avoid introducing keyword (like Java's 'public') or additional syntax for exporting symbols.
leon_ 16y ago
Like the other commenter said: Functions/Fields in structs that start with a capital letter are visible to other packages. Functions starting with lower case letters are like C static and fields are (package) private. I'm not perfectly happy with this convention because I prefer the everything_lower_case_with_underscores style but you get used to it. Go's benefits out weight its awkward quirks by far.

kaib 16y ago

This is actually part of the language. Identifiers starting with a capital letter are exported outside the package, the ones with a lower case letter are not.

uriel 16y ago

This is covered in the basic language introduction: names starting with a capital letter are public, names starting in lower case are private. Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better).

198d 16y ago
Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better). Do you mind explaining this statement a little further, specifically related to Python and Ruby. I work with both of those languages and find the naming conventions to be quite clean and respected. The style of the language is not enforced, but you'll certainly be chastised by any serious developer in either language for doing something outside the norm.
- uriel 16y ago
  The Python stdlib is full of examples of CamelCase, under_score and alltogether. In Ruby just looking at the methods for strings is enough to find this like: "instance_variable_defined?", "rindex", "tr_s", "casecmp", "equal?", "eql?" and more. Yes, it is all lower case, but consistent it is certainly not.
  - lepht 16y ago
    I also find myself wishing that Ruby's destructive (!) and boolean (?) suffixes were either enforced somehow or not used at all. The idea itself is cool, communicating extra context about what the method does or its intended usage, but they're used so inconsistently (even withing the Ruby stdlib) that A) They're unreliable and you need to check the source to find out the behavior anyway and B) It's less predictable whether the method exists with the suffix or without, so you need to either run it and modify your method call if there's an error or check the lib/API docs. This is the sort of thing that makes having an IDE handy for completing method names, which is unfortunate because Ruby is generally very usable without any IDE crutches.
lobster_johnson 16y ago
I see. I applaud new ideas, but personally I find Go's choice visually jarring; on the screen it ends up looking like a train wreck: fmt.Printf(colorizeWithAnsi(strings.Replace(s, " ", "/", -1)); It goes from being mere syntax (like Ruby's elegant use of '@' to denote instance variables) to screwing with the names themselves apparently just to avoid introducing keyword (like Java's 'public') or additional syntax for exporting symbols.

leon_ 16y ago

Like the other commenter said: Functions/Fields in structs that start with a capital letter are visible to other packages. Functions starting with lower case letters are like C static and fields are (package) private. I'm not perfectly happy with this convention because I prefer the everything_lower_case_with_underscores style but you get used to it. Go's benefits out weight its awkward quirks by far.