Finally, someone understands that Allman is not that great, and that Kernighan & Ritchie is the way to go.
Also, Haskell, my guy, you good?
Lisp, are you ok? Do I need to call your parents?
I've written Haskell quite a bit, and I don't fully understand why this is called Haskell style. Haskell code looks nothing like this, the syntax is completely different. For Haskell's syntax I think it works fine, because I never noticed something weird. But this code in "Haskell style" looks absolutely insane
It's sometimes called comma-leading style where you move all the special characters to the front of the line and it is exceedingly common in Haskell, possibly due to how Haskell treats significant whitespace. You've surely seen list definitions that look like this:
someList =
[ 1
, 2
, 3
]
or a data definition like this:
data Color
= Red
| Green
| Blue
| RGB Int Int Int
deriving (Show, Eq)
or a list of module exports like this:
module Foo
{ bar
, baz
, quux
}
Or in a long function type declaration where the arrows are moved to the start of the line, or a record definition, etc. etc.
If you use if (blah) { then when you fold your code you still see the { but not the closing } (I suppose some IDEs might be smart enough to do something about this, but when not it looks like your code has an overbite).
And then you've got a mental disorder if you indent your opening and closing brace more than the statement spawning them.
Noone writes Haskell like that. People generate Haskell like that because layout syntax is a fickle beast to generate and outputting braces means you can make mistakes in layout without breaking things, the way the braces and semicolons are output emphasise how they actually don't matter, they're also easy to delete in a text editor.
Also it matches up with other Haskellisms, e.g. lists:
let foo = [ bar
, baz
, quux
]
See how it's immediately apparent that you didn't miss a single comma? It's also trivial to match up opening and closing brackets like that, even in deeply nested situations.
Not doing that is actually my main pet peeve with Rust's standard formatting.
Allmans what I learnt then went to K&R on my own because it made more sense to me. I think GNU is fine I guess, not the others though. Not that what I say matters I've forgotten how to code and can barely do Hello World these days.
On a serious note tho, I never understood the benefits of GNU's spaces after functions. I don't really mind most of the rest but I just don't get the benefits of 'funcname (arg)' vs. 'funcname(arg)'. Is there a specific reason for this? Personally, I find this to reduce readability because I have to think for a split second whether I'm looking at a variable or a function call.
Of cause this is also due to my habits, but I'm curious as to what the reasoning is.
Honestly I think it's just "spaces before open parens" and at least it's consistent. K&R, which I use, wants spaces before the parens in conditionals and loops but not in method sigs or method calls and the linter at work gets me almost every time I type the word "if".
Fair enough if the GNU dudes valued consistent spacing more than taking function calls as one "logical block". Not my cup of tea but that's what configurable auto formatting is for.