6 ms·

> Idiomatic Go would have you not put on one line what is more clear on two. This is the kind of silly aphorism that sounds enlightened until you think about i

• C1sc0cat 8y ago
  No cramming code into one line is never a good thing when you can make it clearer and easier to read by using 2, 3 or 4 lines of shorter more readable code.
• networkimprov 8y ago
  This. Code density matters! Excessively low or high density are equally injurious to readability.
  • Barrin92 8y ago
    I disagree strongly, at least as far as my intuition is concerned. it's not code density that matters, it's "context density". Long drawn out functions are usually not hard to read because they are long, but because it's not clear what they are about. It's lack of conciseness on part of the programs logic that makes programmers lose focus, not code density. As an example, think of a few fairly long switch statements or pattern matching logic. It's non-dense code depending on your language, but not hard to understand even if long. In contrast, some convoluted Haskell syntax with weird operators you've never seen is almost mentally incomprehensible. On these terms it's true that Golang is not 'text dense' but it doesn't matter, it stops semantics from being overly complicated, and it encourages simple structures that don't go overboard on condensing information.
• Arnavion 8y ago
  It's also not even true, given that `if foo, err := bar(); err != nil {` is considered idiomatic over writing that over two lines.
  • joshuak 8y ago
    Both are idiomatic. I use the two line version. I don't like this form both for legibility, and the fact that it closes over the return value.
  • reddit_clone 8y ago
    They are not the same though. I got bitten by this recently (Go beginner). In the single line form, both foo and err are scope restricted to the if block. Found that out the hard way.
• laumars 8y ago
  Reducing lines of code is not a free exercise since you make up for it with the length of the line and there have been plenty of studies that have shown how longer lines in written text are harder to read then shorter lines. That said, I'm not going to argue that developer will find shorter lines easier to read than longer lines but I certainly do. However it's also not as black and white as "shorter lines are always easier for me to read" either because there are some examples where it makes more sense to have it run on as one line. for example if you're calling a function who's return is only used as the input for another function. eg fmt.Println(strings.TrimSpace(" some string ")) makes more sense (in my opinion) than s := strings.TrimSpace(" some string ") fmt.Println(s) This is why the Go idiom says "what is more clear on two," rather than "use multiple lines even when it doesn't make sense."
  • apta 8y ago
    > studies that have shown how longer lines in written text are harder to read then shorter lines. As are studies showing that bugs are correlated with more lines of code. final var a = if foo() { bar() } else { baz() } is much more readable and strictly less error prone than var a int if foo() { a = bar() } else { a = baz() } > fmt.Println(strings.TrimSpace(" some string ")) makes more sense (in my opinion) than What makes more sense is " some string ".TrimSpace() as it allows for easier reading due to call chaining. Of course the golang standard lib decides something else just for the sake of being different, and without providing a proper reason.
    • laumars 8y ago
      > As are studies showing that bugs are correlated with more lines of code. Sure but do those same studies look at code with the same character count (ie longer but fewer lines) or are they just subtracting characters via subtracting lines. The ones I've seen were the latter in that they basically just said "less code == fewer bugs" - which shouldn't be a surprise to anyone. > [single line code] is much more readable and strictly less error prone than [multi-line code] You know, had you said that 10 years ago I'd have completely agreed with you. But these days I've read so much Go code that I now find the multi-line equivalent more readable simply because that's what I'm more used to reading these days. But we're not really talking about significant margins in either case. I mean you'd expect any developer to parse either statements with ease. I will say that I have always hated reading the ternary operator - which is the preferred way of doing single line if statements in some languages. I'd take the multi-line approach over the :? syntax any day. However from a strictly artistic perspective, the single line version with bracketed blocks is the nicest looking. So I can completely understand why people would prefer that method. Honestly, if gofmt let me, I almost certainly would write code that way too. > What makes more sense is: " some string ".TrimSpace() Your now arguing the benefits of OOP over other paradigms and while I agree that Go's implementation of OOP is half-arsed at best(!!!) I still have no intention of entering into that kind of ideological debate. Sorry.
• apta 8y ago
  LOC also correlates with bugs. This has been shown in studies on more than one occasion.