> 2.1. Choose identifiers for clarity, not brevity This is a real problem in Go these days, people use one and two letter vars quite a bit which makes reading code you’re not familiar with practically impossible. On one project we simply switched to semi-java length like names since our customers couldn’t read the code.
Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.
They usually aren't however they can be an issue if the idiomatic style trends towards towards bad ones.
> 2.1. Choose identifiers for clarity, not brevity This is a real problem in Go these days, people use one and two letter vars quite a bit which makes reading code you’re not familiar with practically impossible. On one project we simply switched to semi-java length like names since our customers couldn’t read the code.
Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.
Dogmatism and Go are peas in a pod. If your variable is longer than one character you're a dirty Java programmer, or something to that effect.
The issue w/ calling it "config" is that you end up with the confusing scenario where "config" is the object and "Config" is the type, differing only in casing.
Why is that confusing? Local variables are, idiomatically, never capitalized in Go, so the distinction is obvious at a glance.
Came from Java world, I find the Go comment and godoc are really limited. We can't link between functions, types. We don't have a standard way to declare input, output, don't have any distinction between a normal word and a Go identifier Refactoring using tool (e.g: Goland) usually lead to unexpected text replacements. Take following functions, for example: // Auth check if user credential is existed in bla, bla... /…
I’d argue there’s a failure of the code to some extent to need such extsenibility with documentation. I’ve often found when I need more info outside of Godocs that simply clicking through and diving into the source provided me with all the answers I needed to know.
This attitude, which I'll paraphrase as "needing any feature that I personally consider unnecessary is a code smell," is endemic to the Go community and a big reason why I still find myself frustrated by it on a daily basis even after a month of using it for a greenfield project. I don't like the language itself, since I'm generally in favor of a language offering more affordances rather than fewer, but it's fine to write in and I'm ultimately concerned with making the pragmatic choice. When I go to look for what the idiomatic way to do something is, though, wow! It's rarely just "this is the way to do it, since the language optimized for a particular use case by making the tradeoff of omitting the usual features for this": instead, it frequently goes on to assert that those features are unnecessary in nearly every case and languages that provide them are wrong, or old-fashioned, or too Academic, or the people that use them don't care about Getting Things Done. Also, throw in a few cargo-culted potshots at Java for good measure! I've used a good number of languages professionally at this point, and the Go orthodoxy is easily the most off-putting I've ever encountered. I don't know why it's become so aggressively totalizing, but it's not a good thing.
Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.
Dogmatism and Go are peas in a pod. If your variable is longer than one character you're a dirty Java programmer, or something to that effect.
Says who? This sounds like teenagers at school... Not like the people who actually created the language and who are notable experts.
I guess it's hard to get around to the advanced features when so few people even bother to take advantage of the basic ones. Documentation for most Go libraries I've come across has been pathetic compared to similar things in Python or PHP. edit: Compare to something like Racket: https://docs.racket-lang.org/plot/intro.html?q=graph#%28part...
Disagree hard on Go vs Python. Python is my day job, but documentation is rough . You're likely not going to get documentation for all the types, and if you do it's usually in one giant page and you can't tell which class's `__str__()` docstring you're looking at. Often you'll have a method with some terse description for parameters that don't completely describe the types accepted for a parameter. Most of this stuff…
> Godoc also has really nice support for executable examples, and examples run as part of the test suite so you know they're up to date.
Ah yes, the nice godoc feature which only got added to the python stdlib in checks note 2001.
Came from Java world, I find the Go comment and godoc are really limited. We can't link between functions, types. We don't have a standard way to declare input, output, don't have any distinction between a normal word and a Go identifier Refactoring using tool (e.g: Goland) usually lead to unexpected text replacements. Take following functions, for example: // Auth check if user credential is existed in bla, bla... /…
The authors have chosen to make it as limited as they have on purpose, as I understand it. I disagree with them, but here we are. I've been slightly tempted at times to make something with markdown but never gotten enthusiastic enough to put the time. Plus, markdown is technically a bit too powerful, so I'd want to cut it back down, and before you know it I'm inflicting the 3,124th custom markdown on the world. Reall…
I'd just like to be able to toggle javadoc, phpdoc, godoc visibility on and off entirely (not collapsed to a line, or a marker) just make them vanish until I summon them back.
I find them distracting when I'm reading the code but I don't want them not to exist either.
EDIT: Another thing I'd love to be able to do is 'tag' a variable with a synonym and have that appear next to it eveywhere.
so $strCstAcctRec (I wish that was fake but it's pretty much straight out the codebase I inherited..) would show up as $strCstAcctRec (CustomerAccountRecord).
There are a bunch of ergonomic features like that I've considered over the years, I might at some point try implementing some of them as an intellij plugin.
> 2.1. Choose identifiers for clarity, not brevity This is a real problem in Go these days, people use one and two letter vars quite a bit which makes reading code you’re not familiar with practically impossible. On one project we simply switched to semi-java length like names since our customers couldn’t read the code.
Since when are variables names a language issue? There is no such thing as "Java length like names", or whatever. There are good practices and bad practices and they are universal.
It's really more of a language community issue, but communities of a language are commonly referred to by the name of the language itself.
> - No err != nil checks (replaced by option types) Where can I find code illustrating V Option types?
https://github.com/vlang-io/V/blob/master/examples/users.v They are very simple and combine Rust's Option and Result .
// `http.get()` returns an optional string.
// V optionals combine the features of Rust's Option and Result.
// We must unwrap all optionals with `or`, otherwise V will complain.
s := http.get(API_URL) or {
// `err` is a reserved variable (not a global) that
// contains an error message if there is one
eprintln('Failed to fetch "users.json": $err')
// `or` blocks must end with `return`, `break`, or `continue`
return
}
This looks really handy. Is there somewhere else (outside of V) where I can read about Option types (in the real world, or in theory).