Video

// make it just a little bit harder on whoever gets to read this in the future {if (!Success) {//return Success; return !Success;}} // Or just get the job done in one line: {bool S=!Success;{if(S){return S?!!S:!!S;}}}

Lol none. This is format. I prefer checking for false then falling through to true.

My typical preference is to put an if immediately followed by a flow statement (break, continue, return, throw, or goto) on a single line immediately followed by an empty line, or braces following language convention otherwise. I prefer the single line if as it shows the intent of an if return/break as a single statement (kind of like the ThrowIf functions) and also avoids the goto fail bug. I don't like having non-flow statement without the braces because that code is much more likely to changes, and I also view it as 2 different statements. In the end though, I mostly do this because it is a rule, and following rules gives some kind of consistency.

MethodInfo.CreateDelegate() would be much faster than Invoke (basically the same as any other delegate invocation which we do all over) but not having to “lookup” the method at all with this approach is quite nice.

Copy and paste just the squirly part 1000 times, then repeat with the first squirly on the same line as the if statement. Note the added time it takes when the squirly is on the same line. Choose the faster and more efficient option.

It’s interesting that they prefer the Allman style now. I thought they used to use the Stroustup in their docs.

Brevity is the soul of wit. Preferring that code has soul, I choose the briefest form, and certainly not a forest of unnecessary curly braces.

Option 4. Then EVERY if statement is the identical style - which means a section/caveat can be removed from a style guide. It also makes diffing better when it moves from single line to multi line. And then it eliminates any potential, no matter how small, of a line being added without braces also being added and unintentionally introducing a bug.

The correct answer is to use the one that your shop recommends in their code standards. My shop recommends the brackets on their own lines for readability. Personally, I prefer the single line for efficiency. Unless its a complex statement.

My opinion behind #1 and #2 is If you use #1 it's really easy to have multiple indents 1 line after the other. For example if(X) for(...) if(Y) This is actually hard for me to read... maybe because of my eye stigmatism or the fact i read very fast but my brain doesn't take everything in quickly. So having #2 breaks everything up more making it easier for my break to separate if(X) from for(...). Typically if i'm reading peoples code and having trouble understanding it i'll change it from #1 to #2 so it's easier to process... but i'm not everyone so I revert it back once i'm done.

My take on this is, if its a one line return statement or throwing an exception , I dont use brackets. If its a linq expressions or something that is one code line but spans over multiple lines in the editor then its already too much. Its th same reason why I dont like the expression take methods. it makes it less readable where it starts and where it ends if its longer then one editor line. brackets for single lines like that makes code less readable.

Is there a gRPC version of this? Many thanks

I prefer using 2 { } on their own line. i think it's just more structured and easy to understand. Yes, even better than the first !

Personally, I never use #3, mainly because VS automatically changes it to #4 (which is, IMO, clearer). #1 doesn't really make sense. It's longer than #2 and not as clear as #4. However, when my condition and my instruction are short, I have absolutely no problem with #2. Mainly for early returns.

If you don't use curly brackets please go back to python 😅 If (true) { DoStuff(); } Of course, everything else is just barbaric 😅 This way it's a visually better way to spot blocks of code

1) whatever code standard is in place for project. 2) my preference If .... { ... } No single line - easy to miss return at end and misunderstand logic. Use {} even if one line in if statement. Fewer mistakes when editing and clearer where if ends. I do not like If ... { ... } But that is a personal preference, feels like wasting a line for no purpose. Whatever the code use I'll follow that style, and that style is not something to waste time arguing about.

I don't like to make rules about this, in some scenarios option 1 or 2 makes more sense and in some scenarios it makes the code confusing ... in my opinion, 1 2 4 in c# are perfectly fine. I just excluded 3 because usually dotnet IDEs don't like it

I kinda wonder if it would ever be possible for dotnet to just cheat with exceptions and avoid the stack unwinding via the compiler by functionally treating any method that throws exceptions without catching all of said exceptions as returning something akin to OneOf<return-type, most-common-exception-type> (would probably be more comparable to std::expected in C++) behind the user's back and all the try block does is evaluate the "underlying type" for the exception case and pass it off to a catch if any of the catches for each relevant type, else the function will return the new most common exception type. Sure its not a simple thing to implement, but neither is stack unwinding and doing that make exceptions just as efficient as the return type case, there are definitely things that need to be addressed in odd cases, but depending on how its implemented and how deep such a system would be placed it could go completely unnoticed except for having massive performance benefits. There were once talks on considering some type of manner to adopt this in C++, but those would take a decade before they see any proposal to the standard.

I use no braces and always attempt to stay vertical so each statement gets a new line. Ideally, you want to see as much as you can in one eyeful. By the way, I am a professional expert developer. Also, in practice, abstractions are better than interfaces, interfaces are kind of a useless piece of code, on debug interfaces become the class so why not just use real classes instead. I came across something recently that said they will start allowing code in interfaces, which makes it more like abstractions .

For me, I prefer K&R style braces (the "Go style" in the lineup here). Functionally it all works the same as Microsoft's preference (known as Allman style), and doesn't have the future-ambiguity potential the no-brace versions have, so for me it's like "Do I want to just have an entire newline with a lone opening brace?" It feels weird to me when I see it, but it's all down to personal preference rather than professional opinion. I can only describe it as something like a stray hair or something to pick at. But it certainly wouldn't merit failing code review or force-formatting an entire codebase for lol

What about an inline else statement? if (isGreeting) { Console.WriteLine("Hello, World"); } else Console.WriteLine("Bye, World");

I never use a single line because code coverage tools will only count if the line has a test covering it not both statements. Code coverage tools can always give a false positive and this is one of the reasons why they shouldn’t used as a metric to determine quality.

I don't need any brackets of any kind in a if statement (in general) when I am using the other .NET language. 😉

Developers that advocate for exceptions instead of Result for non-exceptional situations are obviously not working on large systems. In a large system all the unnecessary exceptions will hide the real problems. They will clutter the logs and the application monitoring will raise false positives.

I use the 4-liner form and sometimes 2-liner. Mostly at the beginning of the method. 4-liner because I am used to it, I could switch to 3-liner, no problem for me. But 1-liner... I want to scream, especially when I refactor the code, and the tool opt to use one liner, despite there is absolutely no 1-liner in my entire code ;-).

I always remove braces on single line IFs, but i always put a newline after it for separation.

In C# i use variant 1, 2 and 4, in C/C++, PHP and JavaScript i use variant 1, 2 and 3. I tend to use the most readable (for me...) version that matches the current needs. eg. variant 2 will be used in case of two or three guard clauses, the returns will be aligned (so this is very rare... but i use it) Precondition for variant 1 and 2 is: everything must be crisp. In Teams i use what the naming conventions says, it's not important that i like it or not! Keep discussions in teams brief about such issues it's not worth it. If there are "discussions", team lead should decide and the will decide for variant 4, that fits all. Done. Get on with it!

I am calling the emperor has no clothes. First, all 4 if statements are valid C#. Second, if any programmer cant instantly read any of these (assuming he is not diagnosed with dyslexia) he should not be programming. I see the problem here as the code reviewer (my assumption is he gets a bonus based on line of codes). He should be looking at the code to see if it can simplified, refactored, have improved performance, or maybe a better new approach can be taken. Forcing a developer to spend time replacing valid C# with valid C# for such a simple condition is reducing, not enhancing, productivity and is wasting the companies money. Without showing a valid increase in productivity, I, personally, would remove him from code review. Let me use an analogy to show this point. Imagine two workers building a SpaceX raptor engine. Both tighten bolts to specifications but one uses his left hand and one uses his right hand. The quality control engineer looks at this and says to the person who tightened the bolt with his left hand, a right handed person might get confused if they watch you and try to tighten the bolt with there right hand and cause problems. Now go back to every raptor engine and un-tighten your bolts and re-tightened them with your right hand. They would be fired on the spot! The quality engineer should 1) make sure the bolt was tightened to specification and 2) look for ways to increase productivity like adding a robot with a power torque wench to the assembly.

3 or 4, I always use braces because it's easier to not make a mistake when adding code later (see heartbleed). Where the braces go depends on the project's preferences.

I personally prefer #4, i've had instances in bigger methods where I quickly misread #3 as #1 misjudging the scope (Especially in cases where something didn't gell with a auto formatting orso.), not a big issue I suppose but still.

I write both C# and TypeScript all day, every day. K&R indentation and I use all those styles of "if" and more.

Now the more important question: "if(" or "if ("?

I cling to the hope that one day C# will offer a Python style option where block structure can be inferred through indentation.

For cases where it's unlikely that there will ever be a need to add more line, such as early exit guard clauses, I prefer the single-line, no brackets version. For other cases, I prefer the multiline with brackets on their own individual lines. I am perfectly willing to accept using brackets on the single-line version or having the starting bracket for the multiline version on the same line as the if. These differences are just a matter of preference, and I'll follow what the project does without discussion. If a project wants me to use a multiline version for simple guard clauses, I'd probably grumble about it in private, but comply. And finally: The multiline version without brackets is a bug waiting to happen. It should never be used.

Why does it need to re-specify "src" if parent node has yet an "/src" attribute value?

I never thought bout this. If my If statement only has one line in it I usually use If(success) return true; the brackets seems obsolete to me there. Isn't it all about readability in the end? I don't work for companies and I only do it for my personal gain so I'm the only one seeing my projects so bassicly in this case it doesn't really matter as long I consistent with my coding. Thats my believe about it.

I like to have braces everywhere for consistency's sake....and as for the braces I prefer #4...It's just neat.

You need to put the if-statement into a context where different ways to write if-statements makes more sense. It is all about context and readability and the "feeling". I been in many code bases contaning multiple if-statements with ms-formatting, then it is hard to see what is going on. Consinstancy is great but can also be a curse!

1:40 it's not just about C# being inspired by Java, or looking similar. Microsoft tried to extend Java in shady ways ("Microsoft breached its contract by trying to extend Java so it would work differently, and presumably better, on Windows computers"), which pushed Sun to sue Microsoft. That lawsuit ended up getting settled with Microsoft paying $20 million to Sun, and receiving heavy restrictions regarding how they can use and influence Java. Basically, Microsoft ended up making C# because they were legally forbidden from further messing with Java. So really, that jab was not just about C# / .NET being close to Java as a language / framework.

Option 5: return success;

i prefer the first one. because i often have many separate if statements following each other, to do different checks on a value and throw an exception. if there is an else clause involved i may opt to use the second one. but this is a silly discussion that we shouldn't be having

If you need to have absolute control over formatting, then work on some personal/hobby projects. Joining an existing team and globally applying your own formatting preferences is antisocial. If you do it, your teammates will make nasty comments about you behind your back (at best). That said, this is inexcusable: if (success) { return true; } Done once, it's a mistake. Done consistently, it's an indication that whoever wrote it refuses to use idiomatic C#. I don't have time for that.

I think this is actually not that important. I always like to use an opinionated code formatter like Prettier or CSharpier. There a decision has already been made and I do not need to think about this stuff. After some time you just get used to it. I started with C# and now mostly work with Typescript. C# normally uses #4, Typescript normally uses #3. In that case I used Prettier and just switched to #3. Whenever I write C# again I use CSharpier which uses #4. It really does not make a big difference. The most important thing is consistency IMO. In regard to #1 and #2 - I think it can be ok to use them. I would not necessarily reject a PR if I see this, but in most cases I try to avoid it.

I use #1 when i return literals (e.g. null) or when i want to make a single mathod call and it's signature is not that long. It reads better in my opinion when the statement is very concise. I use #2 more consistently when throwing exception in guards or calling methods with a long signature. I never use #3, when i add brackets I follow Microsoft's convention. #4 is for all other cases, where the if enters a multi-statement block (obviously) or when the single method call/return statement spans too many characters and I have to subdivide it on multiple lines (for instance, say, a method with 6-7 parameters). I don't really agree with the reasons you gave for why #1 and #2 are confusing, since whoever uses wrong tabulation and writes a second statement after a semicolumn without starting a new line clearly has a very different opinion on coding as a whole, not just brackets

I dont like scrolling for little reasons. So i do not use braces

I use the last one. I think it reads better. especially if you're reading something with nested functions (not best practice) I'd love a deep dive into Microsoft identity and azure in c#. if you guys have a course

The answer to all questions: It depends. If I only have an if statement with a single return, then I write the return in the next line: if(...) return ... but if I have several if-statements instead, which also only ever have one return line, then I write it on the same line: if(...) return ... if(...) return ... if(...) return ... In the meantime, you can often replace these if statements with pattern matching. In cases like this one: if(...) return ... return ... I use the ternary operator to create clarity: return ... ? ... : ... I don't think it gets any clearer with brackets either. In my opinion, brackets visually bloat the code in these cases, but to be honest, I don't care. I can live with all situations. I used to develop mainly with Java and now with C#, so I'm used to all kinds of bracketing and go with what the majority of my teammates say. In private projects, I use the notation mentioned above. I also leave out the brackets in the using keyword, as I keep the methods very small anyway, so that the Dispose() should only be called at the end of the method and not in between.

It uses the same order the token appears in the template string as the argument array, right? Like ("{a}{b}, {c}{d}{e}", 6, 9, 4, 2, 0) will become "69, 420"?

How much of this will matter in 2 years when copilots are writing most of our code? See you in 2026. I don't like parsing out what is going on one line. If is one actionable item, return is another. Separate lines for each actionable item. After that I just keep braces in line with the rest of code. All my statements will format like the class declarations.

Same way with the getters. If the logic is small (eg. return bool) i would write it in a single line in blocks, What matters, is to write it in some consistent way, that is not distracting you about scopes etc.