I fucking hate two-space indentation. You might as well not indent at all.

one space anyone?

@We3D AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Imagine using spaces/tabs

@devRancid based

Two spaces are great for anything but IDEs. For example to share a snippet on something that could be viewed on a device with a constrained screen size like on devRant on a phone.

looks alright in small yamls though

“Nah dude I don’t use indents because my code is just a huge one liner because I’m 10x dude”

@chonky-quiche classic sh script type energy

Am I the only one here who can read 2 space indentation no problem at all?!

@devRancid now try that with opening braces on new lines

@AlmondSauce yes

@chonky-quiche my point is I can barely see the indentation with that.

fine, 3 spaces it is!

@electrineer sharp as a katana

Great way to tell if someone is a JavaScript child.

I'm happy with any indent my tab button produces

@mansur85

There is no such thing as a C standard indentation.

The closest thing to that would be the K&R style used consistently in The C programming language book, which is one four-sized tab.

@mansur85 we need @netikras gpt bot back. Chatgpt about this issue: In the C programming language, the default indentation is not strictly defined, as it is a matter of coding style and personal preference. However, most commonly, developers use four spaces as the default indentation level to improve code readability. Some developers may also prefer using tabs for indentation instead. The key is to maintain consistency within a codebase for better collaboration and understanding.

@devRancid i know an agent of chaos when I see one

@mansur85 I've read the book but don't remember

What's wrong with 2-space indentation? I find it elegant, actually easier to read since my eyes need not to jump as much

@mansur85 @retoor
frankly enough i usually also code with 4 spaces almost everywhere. And that's how i got it taught back in Turbo Pascal and C days.

human readable configs usually get two spaced tho, if they're jsonlike. I kinda dont feel like scrolling to the right, when having them open on one half of a screen.

@electrineer i-if that's an insinuation that I'm writing this rant for the "rant points" or whatever they're called, I'm actually offended lmao

@CoreFusionX I work with JavaScript, but our entire code base is four spaces and this guy is letting his linter make every file he ever saves get converted to two spaces

@nururururu

Those deserve a special place in hell.

@mansur85
Direct capture from the book.

@nururururu that is actually kinda funny.
I assume you guys don't have an auto formatter of some sorts in the CI/CD pipeline?

@mansur85

Sure, whatever you say.

Your random 'trust me, bro' level "source" is now in charge of some imaginary standard.

@CoreFusionX now why does it say that you m͟u͟s͟t͟ have your file name end in .c?

2 spaces for { and 2 spaces more for the content.

See attached image. It makes the return statement to a single line statement, including { and } and it is still readable.

Show me a style that is easier/faster to read.

@happygimp0 anything than this 😆

@happygimp0

for(…) {
if(…) {
return -1;
}
}

Ahhh, much better.

@mansur85 to be fair, your prof suggested 3 spaces are probably their design recommendation, and only because you take their recommendation, doesn't mean it's common. Profs are just people at the end of the day, the one who taught me stuff at university hated git branches. Does it mean i'm not using them now? Hell no, branches are good and useful and sometimes necessary, especially in a world of CI/CD and Pipelines.

At the end of the day it shouldn't matter if you use auto formatting tools tho.

https://ccapitalia.net/descarga/...

@mansur85 found the first edition. If K&R actually would have taught it that way, they would have surely put it in there, no?

@electrineer

Because, you know, that is actually, while not a standard, a convention. One that is fully adhered to.

@mansur85 the thing is, that i can imagine:

The nowadays known K&R with 4 spaces is a variant, that became the de facto standard for K&R.

It sounds plausible, if you remember different K&R Variants, such as the Linux Kernel K&R Variant, that uses 6 Spaces i think (or 8, i'm actually not sure rn).

But it just would be weird, that the authors of the original C Language Book would not use their own convention they themselves established.

@thebiochemic maybe they reasoned that for a printed book, it makes sense to use a different number if spaces that in an actual IDE or text editor.

@thebiochemic we do not :(

@nururururu according to this you do:
https://kernel.org/doc/html/...

@thebiochemic I mean, specifically we don't have anything setup to normalize indentation size on CI/CD and such

@nururururu ah that's what you mean ^^

@Lensflare By all respect, but this is a horrible style.

The { and } don't line up. It is easy to forget a { or }. It is hard to see where a block starts and where it ends (without the indention. But the compiler looks for the { and } and not for the indentation.)

Draw a line from every starting { to the } If it splits the code nicely into blocks, the style is easier to read. If it goes through the code in a messy way, it is a bad style.

@Lensflare "anything than this 😆"

Why?

@happygimp0 we had this discussion already. It’s subjective and a matter of personal preference.

For me it’s much more readable. { and } don‘t have to align horizontally. I can see the start of the block by just looking at the first line which is indented the same level as the closing }.

@Lensflare No, it isn't just personal preference.

The compiler starts a block at { and ends a block at }. If your style doesn't reflect that it is objectively worse than a style that does reflect that.

Personal preferences are things like how many spaces or tabs you use per block, if you put spaces around = ... But where a block starts and ends has a clear objective answer and that a { has a corresponding } is also a fact (in most languages).

But, using indent guides. Coloured, preferably.

@happygimp0 what are you talking about? The compiler literally doesn‘t care about the style of {}.

You could write

if(…)
{
return -1; }

or

if(…) { return -1; }

all in a single line

And it‘s syntactically and semantically the same as any other style.

It‘s just a style. Exacly like the number of spaces or tabs that you prefer.

You sound very confused about this.

@happygimp0

By your own admission, what the compiler sees is what is "right".

If you follow the same grammar the compiler does, it's the same to identify blocks no matter if they start on a new line or not.

The grammar specifies what can open a block or not, and anyone with a reasonable commanding of the language can recognize them.

But there's no enforcement, it's a matter of style, so that's a weak argument.

Meaning, if what the compiler sees is right, according to you, then anything that compiles is right.

Boy. Are you in for a world of pain 😁

@Lensflare The point is this: The compiler only sees the { and } and ignored indentation.We see indentation at first and mainly use indentation.

So the style should create code where the { } matches the indentation.

@CoreFusionX The compiler sees {} and that is what defines a block, correct. But we humans mainly use indentation. So why create a style where indentation and { } don't match?

@happygimp0 I'm almost sure someone will say b/c that reduces the lines num ;)

@We3D that‘s just a positive side effect ;)

@We3D Look at my example above. You need exactly the same amount of lines even when you hide the { on the same line as the previous block, because then you need an additional line for the }

@happygimp0 caring about the amount of lines is old fashioned. We want it clear and descriptive these days

@retoor true. Specifically long function chains or expressions should be broken into subexpressions and stored in variables with descriptive names. Which automatically puts them on separate lines and increases the line count for better readability and clarity.

Putting { on an extra line however is pure style preference and doesn‘t make anything more readable or clear.
So the extra cost of one line is kind of relevant here, because it adds up.

@Lensflare I'm happy with any formatting of my editor. I think import sorting is a bit weird tbh. Alphabetical for example. I prefer that it makes sense in comparison with your code. So you already have idea of flow

@retoor Agree on the line count point.

How do you sort import then? I don't want them unsorted at all (i need a fast way to check if i already imported something).