Anything but K&R is psychopathic, fight me
this post was submitted on 10 Feb 2024
224 points (100.0% liked)
196
16447 readers
1849 users here now
Be sure to follow the rule before you head out.
Rule: You must post before you leave.
founded 1 year ago
MODERATORS
Allman if the condition is very long
while(isSomething
&& isSomethingElse
&& nFoo < 10)
{
bla();
bla();
}
vs
while(isSomething
&& isSomethingElse
&& nFoo < 10) {
bla();
bla();
}
Hmm, I think the condition gets newlined and you K&R on the closing parenthesis IMO:
while (
isSomething
&& isSomethingElse
&& nFoo < 10
) {
blah();
blah();
}
You could also keep isSomething on the first line too, but I think it's nice to keep the whole multiline condition at the same indent width
This is the way.
Allman is allright, anything else I agree.
No no, you're speaking the truth
Isn't Java like this? Everybody I know who codes java does it like this and I've been trying to follow along despite it looking stupid.
I had to look this up to verify that these are not only real styles, but there are/were some individuals had the gall to make other people consider these awful indentation styles. Of course it was only the C gods themselves to actually come up with something both readable and aesthetically pleasing.
All joking aside, I'd have to imagine some of these make more sense when applied to languages other than C. Even still, there is clearly one true winner in my book.
Yes, I totally agree with you. There is no better style than Whitesmiths.
Every C-inspired language with curly braces (which is a lot of them) that I know uses some variation on K&R/Allman.
Golang straight up enforces the "K&R" style and doesn't recognize a curly brace on a new line. I don't know of a JSON prettifier that doesn't use "K&R" style either.
Unless you mean that the Haskell/Lisp styles make more sense in Haskell/Lisp, which, yeah, obviously. Hopefully no-one actually writes C code like that.
I was for long a long time using Kernighan style, but recently switched to Allman. Everything is suddenly more readable. It's a journey.
This! Similar journey for me going from K&R to GNU!
while (x == y) {
func1();
func2();
}
notice the newline
Bruh
Won't even compile in languages like Go though
Good thing I dont use Go. Primarly php for work, c# for hobby racing game in unity.
This bullshit is why I use Pyrhon
For concise, FP-style scripts it's quite neat. For complex OO software? Pass
Wir sind eine diskriminierungsfreie Gemeinschaft.
While I respect K&R formatting, you can pry Allman from my cold, dead hands.
Please add this to the list of things I will fight Richard Stallman about
love wins !! <33
We love them all <3
I feel like I'd use Allman for large blocks of code (though in those situations it's probably better to stick the code in a function first) and I'd use K&R for 1 or 2 lines of code (like calling a function).
I was a K&R guy forever but I've been learning C++ recently (I know..) and I've found myself gravitating towards Allman more and more
K&R has always seemed like home to me, but I agree that Allman is pretty alright
I used Allman in my C# days and the spacing always felt weird to me since i came from java :(
I started as K&R myself due to work but switched to Allman for personal stuff and I much prefer it.
I'm used to K&R so no real need to switch, also my IDE by default formats in that style. Allman also looks fine, most of the others just seem to make code less readable.
the paint bucket tolerance was too high before and fudged some of the text
hot take: python using whitespace to format rather than curly braces and semicolons is cool and epic, actually
I formatted all my C code in High School with the GNU style. I'm not sure my teacher even read the code :P
I mostly write Lisp today, but that GNU style still has a special place in my heart. As long as it's automatically formatted, I'm fine with whatever style, though.
👍
Haskell style would be a recursive function
I've never seen Haskell used, but it looks the most readable. I would consider using it if I didn't think it would piss off other devs.