"Remove Braces From Your Code Now!" | Code Cop
Вставка
- Опубліковано 17 жов 2023
- Use code TDD20 and get 20% off the brand new Test-Driven Development course on Dometrain: dometrain.com/course/from-zer...
Become a Patreon and get special perks: / nickchapsas
Hello everybody, I'm Nick, and in this video, I'll show you one of the worst pieces of advice I've seen for clean code, backed by one of the worst arguments.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet
Using braces in your code is advantageous, especially when working with a team using Git. Consider the scenario where you don't initially use braces, and later you decide to add an extra line to a for loop or an if block. In this situation, you'd have to introduce braces. As a result, the Git diff will show both the newly added line and the changes where you added the braces to the loop or block. Had you used braces from the start, the Git diff would simply display the single line you added.
That's true! Since Nick shared this advice with using braces I started following this. However, I asked myself: "Why should I even do this if it can be one-liner?". Then I thought and understood that it's way more convenient to expand the code in the future. That's a good point with Git, actually
Also the reason for adding trailing commas to things
(1) Please don't assume Git is the only source control tool. It isn't, and this comment applies equally to all of them.
(2) What teams AREN'T using source control in 2023?
YAGNI says that it is a bad idea to add code just because you might need it in the future. Refactor when it is needed, don't over-engineer from the start.
Anyone who can't grok a change if it involves brackets shouldn't be coding.
@@BittermanAndy🤓
Back in a day I didn't use braces for single line stuff. But then I grew up and realized that it's bad. I agree with all points Nick raised. My other point is, working in a big team, merge conflicts could happen more often. It's a real nightmare to resolve one if change goes from single line without braces to multiline with braces. It's so much easier to have braves from day 0.
Always adding braces has another benefit, even when working alone: if you need to add code anywhere, you don't need to add braces, because they are already there, consistently. Like if you wanted to add log instructions in one of the loops of that Factorise method.
Same here, I used to skip braces for single liners, or even writing if() return statement in a same line.
But now - for many years already - I'm using braces ALWAYS.
It makes the code consistent and it's much more readable and easier to understand the scope.
This also reduces merge conflicts and lowers a chance to introduce bugs in the code.
Here is an example how the code looked like in one of the legacy projects I worked on:
if(IsThisConditionTrue && IsThisOtherContidionTrue) return true;
{
return false;
}
If the rule is to always use braces, then it should look like this:
if(IsThisConditionTrue && IsThisOtherContidionTrue)
{
return true;
}
{
return false;
}
Which would make it obvious that you don't need braces for return false and the result should be like this:
if(IsThisConditionTrue && IsThisOtherContidionTrue)
{
return true;
}
return false;
@@laulaurisjScope is irrelevant for signal line statements. You can't instantiate variables in single line statements. 😢
@@laulaurisj I get your point, but as for that particular example, I'd generally just write it as return IsThisConditionTrue && IsThisOtherContidionTrue; :)
Or possibly two if conditions in order to clearly separate each case.
if (IsThisConditionTrue)
{
return true;
}
if (IsThisOtherContidionTrue)
{
return true;
}
return false;
But yeah, I always put the braces no matter what.
@@zabustifuand like so you just introduce a new Bug since both condition in the previous sample had to be true to return true 😅
As usual, I'd say: It depends. For guard clauses at the beginning of a function I prefer to omit braces, because it's basically always a one-liner like "if something then throw/return". It adds to the readability to keep the guard cause block short (vertically) before the happy flow starts. On the same page, if you basically have conditions for the happy path and the else branch is just a one-liner, or a throw, I prefer inverting the condition to reduce nesting and omit braces for that one-liner, too. In all other cases: Always with braces.
I do exactly like this as well and find that the overall method looks cleaner, but I would never do it in a nested loop as in the example.
I was going to comment the same. I use a single line "if -> throw/return". But not for anything else.
Same :)
I agree on all points there. And the removed nesting helps much more than the use/avoidance of braces
Honestly, I don't mind either, both are equally readable to me (I would put an empty line before the return in both cases), but I'm quite comfortable with indentation based languages.
This isn't really a technical debate though, it's a stylistic one. On code style, I would love if C# just took a much more opinionated stance and introduced a "fmt" tool that covered all of these issues and eliminated code style debates entirely, its wasted brain cycles.
Generally on the, "X said so, so you should do it" matter. Definitely agree. Understanding the context and why someone advocates for something is critical, never blindly just do something (cargo-culting).
Well said.
I second this.
The reason braces add readability is mainly because you have an (almost) empty line. By simply placing an empty line before the return statement and also before the first 'for' it is just as readable as with braces.
But since I program C# I use the C# promoted style with braces.
The problem is C# isn't an indent based language. Adding a new line and forgetting to add the braces will introduce bugs. It might not in python for instance but definitely could in c#.
It's not stylistic, it a real thing actually, just not something to do with coding and more to do with how your brain works when scanning for information, and why the Allman style makes your brain "work less", or "shortcut faster" more so. In the Allman style, which is your common c/c++/c# style, your braces provide a top and bottom "visual anchor" to the scope. The moment you process the {}'s you know all there is to know about that "block". Indent based styles provide no visual anchor at all (empty space!=visual anchor) and K&R seems to be missing the top one because it's not where you'd logically expect it, ie, straight up. Then there's even worse style that mix oddly placed visual anchors AND oddly placed empty space.
Back in the day, it somewhat made sense to make your brain "work harder" because terminal real estate was at a premium, but these days? Pick the cheapest 1080p monitor you can find, pop it in portrait mode and never think about it again...
p.s. if you want a nice analogy to our own functioning, it's in the video. With braces you get those nice "delimiting lines" on the editor. No braces, no lines. It's not because it can't be done, it's just because it would take more work to do it.
I think it's not just stylist. I've seen an idented line after another one inside a if() without braces. The person who wrote the code thought it would work.
The only time I remove optional braces in C# is if it’s a very short one-liner (usually some validation, throwing an exception, or returning) and it has no nesting. Basically, if I have to think *at all* about where that block ends, it should get braces. The first case Nick shows is a clear example of needing braces.
The key word: one-liner. If it no longer easily fits into the same line as the condition, into braces it goes.
Returns and error throwing are the only place I now do this but only on conditional statements.
I generally exclude braces for single lines in the block, but I'm also a fan of including line-breaks between variable declarations and blocks of code, so my version would look similar but more spaced out for readability. I don't generally do this when it's nested more than one or two levels at most though.
I also like that approach.
I'm using brackets all the time and in my company we decided to force everyone to do this also.
- It's easier to read
- It defines the range of the variables
- It's easy to add some additional debug info if you need it for any reason. Even if you need it just for 15 seconds it;s still better to no create and remove again braces but just to keep them there
If you work in JIT company those 15 seconds is 100 000$ save. I go all in for braces being OK if not overused.
I use OTBS over K&R specifically for your 3rd reason. Yes braces adds 1 more line, but the amount of times that I needed to add something that I had to go back and try to wrap the single line with braces was more than enough to simply hit the open brace key (which the ide auto populates) than to go back and try to edit later.
The range/scope of variables is completely irrelevant for one line statements that can have their brackets removed.
The whole reason behind Uncle Bob not liking braces is because he subscribes to the "Every method should be four lines or less" mantra and that if you have braces, it means that the contents of that brace can be extracted into a method.Personally, I like to do no braces where possible for a similar reason but it's ultimately the equivalent of tabs vs spaces or brace on new line vs brace on same line.
Old time computer screen was just 80x25 chars. So four lines that time and now is different four lines. 🙂
Yes but that reason was beacause of the low resolution back in the day when he wrote Clean Code.
Try to have at most 4 lines per method, and try to tell me that it's redable.
As long as you can cover your method withunit tests - you've done it right. That "one method = four lines of code" mantra sounds a bit silly to me 😂
@@MaximilienNoal What, you don't find 20 lines of functional code split into 5 methods across 3 different files, all with 1 usage/reference, perfectly readable and clean? Heresy.
I like quote from the Primeagen: "Readability is a function of familiarity." It means that readability is heavily dependent on how familiar you are with something. That sounds kind of obvious, but a lot of people tend to give advice as if readability was absolute metric. It's not. When I started writing Go, I though that function parameter type after parameter name without colon is weird and unreadable, but now I genuinely don't care. *The most effective way of making something readable, is being consistent, because that way everyone is familiar.* Just follow your team's or language's conventions/use linter or formatter and you are good.
Sure, but if that's your argument then just stop using linebreaks and whitespace entirely. Over time you will become familiar with it
for single line I use no braces, otherwise always braces
so since the outer loop has 2 lines, braces, the inner loop has 1 line, no braces
so a mix of both in this case
Yeah, this
This is exactly my rule of thumb, but generally I don't apply it to loops only conditional statements.
I have one more rule: if the controlling statement (if, loop) consists of multiple lines, I always use braces, even if the inner statement is a single line.
Yep. Exactly the same.
I use to do that, but now I do the opposite.
Feels IMO more logical to have both 'for' together and then open the braces, the case in the video may not be the best example but if you are to loop on a 2D array it makes more sense to me.
I use no braces for single line.
Very often this single line is just "return;" or "throw new SomeException(...);"
Otherwise I always use braces.
start using stuff like this "ArgumentNullException.ThrowIfNull(nameof(entity)); " on null exception instead.
If not, add in an extension on the Exception. you'll avoid the whole if in every place of your code.
FYI. ArgumentNullException.ThrowIfNull was added in C# 10.
I tend to follow this. Makes the code readable without taking up too much space.
I think the code sample without brackets is preferable. There is no functional difference between the two samples, but in my opinion, the usage of braces can make the code more challenging to comprehend. Braces are eliminated, resulting in a more compact code and a decrease in language-specific grammar. Because of this, reading on a screen may need less movement of your foveal vision. Further enhancing readability is the use of indents to denote parent-child relationships in next lines.
I actually like it without the extra braces. I have no problem at all reading either block, but to me spreading it out with braces just means unnecessary scrolling.
I also prefer without extra braces.
Having multiples braces just take more time to read and scroll
how 8 lines like that is more readable than 3 ???
if (bla)
{
c++;
}
else
{
d++;
}
BUT, it's a personal choice.
NEVER force a developer to use short or long version !
And NEVER NEVER change the code of someone else in your team
I too like the no extra braces example as well, but I would probably leave some space before the return statement so as for the reader to know what is being returned as well as the variable arrangement at the beginning. As most people said though, it's personal preference tbh.
Sometimes more code is a better code. Everyone should know it.
Exactly! People tend to think that clean code = less code
At this point I just read Uncle Bob's tips for clean code and do the opposite.
I agree.
@@gileeeLast week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles... They all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.
Joel Spolsky
The only time that more code is better is if the code is extremely important. It is more readable if, in general, important code takes up more space than insignificant code. Unnecessary braces rarely fall into this category.
I spent so much of my early career changing my mind based upon my "idols". I've attended conferences, I've attended training courses and at this point the way I put it is. "The code should be the teams that is working on it. What matters above all else is that the team that is working on the code should be able to understand it without much delay, change it quickly, test it effectively". In an organization, standards matter, but those standards can and should evolve. I'm over the half way mark in my career at this point, and I stopped following a lot of the people because it was just noise that confused me. Not to say I stopped learning, I'm always open for growth (why I watch these videos) and what I do today, I may not do tomorrow.
As for the content, yeah, I would absolutely not remove those curly braces. But, I'm also one of those that would put a blank line after the list declaration and a line after the last curly brace before the return. If we're writing small, readable functions then the visual demarcation with the space of variable, action, result aids in readability for me.
I like no braces on simple short-circuit conditions like
if (x == 0)
return;
rather than:
if (x == 0)
{
return;
}
And now one day you need to add something like:
if (x == 0)
Logger.Log("Did it really came here?");
return;
And for some reason it stopper working, because there were no braces and you forgot to add them :D So you're adding them, and a few minutes later you don't need then anymore... for a week or two... I've seen this so many times... it's better to just add brackets anyway
Same but i stack early returns with single lines and leave a space below instead as long as they are basic. E.g.
if (user == null) return;
if (x == 0) return;
... rest of code
I prefer my code to be uniform and given for anything other than a 1 liner you need braces (ignoring switch statements) I’d rather always use braces instead of intermittently. I also think it’s easier to read and looks better, although that’s subjective
Sometimes, braces inside of switch case statements will save you (variable re-use, etc.).
@@TexasGit Yeah agreed but usually I don’t bother with switch statement braces
You are absolutely right Nick; however, the advice in itself is good advice: i.e. remove UNNECESSARY braces, what the OP has failed to realize is that those braces which he (I'm assuming a guy) has removed are in no way and by any stretch of imagination UNNECESSARY. Necessity (with respect to braces) is about whether or not they help to understand the intent and scope.
Uncle Bob NEVER said "remove braces from your code"
I always use brackets.
Especially since the Apple SSL bug. When they dropped the brackets, and put a security hole in the system.
The issue I have with this advice from both perspectives is that is simply personal preference. My code may get rejected in a code review for either of these approaches when they both do the same thing functionally. The argument that one is more readable than the other is null and void as, generally speaking, what's more readable for you isn't necessarily what's more readable for someone else.
I'm enjoying this series, so many additional opinions and views when looking at something that I've had arguments over, I always add braces to my loops so I know what is being looped.
I omit braces for one-liners as I prefer more a compact view. I would add empty lines before and after cycle though.
Great video and you've really given me something to think about.
I've always removed braces when they've been used to wrap a single line of code. My reason for doing this was to reduce the number of lines of code to ideally make the code overall, easier to read. My driver for this was to make code more maintainable and easier to consume by more junior developers.
That said, I can see your point and can't argue that clearly identifying the scope of the code via the use of braces really makes the code blocks stand out.
Relying on tabbing to be able to identify the scope of the code has it's pitfalls.
I think it depends on how intuitive the code is. If you're reading code in an app you're really familiar with, you know what the author is trying to accomplish at a high-level, and you're familiar with the low-level libraries/details because you also operate in that space, then you can parse it without much effort.
In this case, I don't mind when the braces are missing. The code becomes more compact, so you can scroll through it fast. It's more comfortable to sprint through the code like it's a 400m dash instead of 400m hurdles, where you have to jump over braces every few lines.
Now when you're reading new code that makes you feel like you're stumbling through a dark room, then you want the handrails. You're not able to sprint through the code anyways, so the braces can only add explicit clarity without slowing you down anymore than you already are.
I can imagine for a team, especially in big projects, you'd probably prefer to err on the side of caution and go with braces.
In C#, I never omit braces. The consistency and convention of brace in a newline keeps a constant way of looking at things.
@@IIARROWS Just use auto-implemented property
@@IIARROWS Why would I define a property like that; int A { get; set; } is fine. For small content, braces on the same level is ok. For control flow statements though, always new line.
Great video Nick! Always watch your videos and often learn new perspectives and adjust my own thinking. In this video I wholeheartedly agree with your point on scope. I tend to drop braces where I can as I like the look and readability without. That said your main point about scope challenges me to reconsider too. I am comfortable with reading my own code without but also agree with you especially where I need to read someone else's code.
If you are really interested in what the very exact loop/statement is doing, then yes, having braces/blank lines around it will help you to distinguish it from the rest of the code.
But the majority of times you just skim through the entire class/method, looking for some particular place. Then you're not interested in the particular loop, you want to 'skim' through it. And then all those braces are just visual noise.
Notice, how all C# development goes into a direction of removing excessive braces:
body expressions, method-wide using statements, single-statement lambdas, etc.
It's the same as with ternaries: you might argue, that a full if-else is more readable, when in reality some people are just not used to see it enough
In the context of multiple for/foreach/while loops I always add braces. Basically, as soon as anything inside the scope of the highest-level loop is multi-line, I add braces to all inner scopes as well. I like the consistency of it. Anything multi-line should have an explicit scope.
That said, I don't mind the no-braces if-statement as long as the content is indented. It reads fine to me.
As a sidenote: I love the ruby-style one-line if statements. I want those in C# :D
``` Ruby
return true if someCondition == true
return false
```
I prefer the first. I can read the second no problem.
Question. What do you think about switch case, with braces for each case?
I personally prefere to omit braces if it's one line in the statement, any more and braces should be there. In your example the innter loop braces can be omitted, the ones of the outer one not.
I generally prefer the first version.
Although I _do_ stray away from that when doing precondition checks that either return or throw.
Then I usually _also_ put the if and the code that is executed in the same line instead of introducing a line break.
My arguement for using braces even for single line statements is merging changes between other developers.
For example,
If(false)
I++
I++
Well give the value of i as 1. This could have been the result of a botched merge where different devs intended to add the same increment to only be triggerd once, but because c# only scopes the first statement after the if, things can get very messy.
As devs we need to always keep in mind that our work isnt perfect and may change in the future; protecting ourselves and future devs need to be a part of the wotk we do.
Wanted to ask you Nick what do you think about round braces? (function arguments, in scope of C# of course)
So in my own code (of course teams usually don't use this approach, because of standard linters)
I use them, in the same way as curly braces, besides few moments:
- function arguments preferred to be in the same line, if it is possible,
when body of scope is always preferred to be on new line
So if I have several arguments (those could have long names, when you write some business module)
and they do not really fit into one line, I start to use round braces to sign a scope of arguments like so:
public myMethod
(
int argument1,
int argument2,
int argument3
)
{
...body
}
I wouldn't even think of removing the braces for loops but I don't use them for one line ifs... Is there a situation you would ever say it is ok or even recommend to skip the braces? Or would you just always recommend using them?
I think the most important thing is to pick something and stick with it, at the very least within a single project but preferably across all of your projects that your team works on. If you insist on reducing braces down to as few as possible, then do that through the entire project, not just sometimes. It gets really confusing when you hit a section of code that is 'compacted' like this when there's other code around it that isn't.
I'd say that just always using the braces is the better way simply because the IDE defaults to wanting to do it that way, so it's the path of least resistance. Trying to eliminate the braces requires everyone tinkering with their IDE to get it set up the same way or fighting with the IDE to remove them when code completion puts them in automatically, leading to wasted time and inconsistency in code formatting when someone inevitably doesn't notice that the IDE snuck in some braces.
I've had that debate thousands of times. I advocate for brackets even when your IF statement has only one single line of code, even it it's "x++". Brackets make my C# "trained" brain find the path and logic without searching or analyzing "who controls who". Removing two characters from your code to make it easier to read is lke rmvng chrs in yr txt cause the rcipnt will undrstnd ayways. Come on!!
Godsent here
Why waste time use lot character when few character do trick
@@jacobstamm but braces are added by IDE. You don't even have to think about them. And where is the time wasted? By adding braces? What are you on about?
@@Velociapcior Relax mate. It’s just a famous line from The Office.
However, those two characters drop the amount of code you can have on your screen by two lines. Being able to view more code without scrolling improves readability.
In my Code, there is by default exactly one line under each if-condition. At this point, the braces are actually doing nothing except for adding two lines of clutter.
That is no dogma, but a communicated decision within my team.
Funnily, now the braces indicate a breach of style, if used.
For a while I removed braces, but I noticed that in foremost later refactoring it was generating a lot more problems where a new developer went in to maybe add a log statement or something else that was meant to be in the same scopet, but forgot to add the braces back so it happened in the outside scope of the intended scope. So these days I rather have a couple of extra lines of braces code than to remove them.
I personally omit braces whenever the situation allows because I am very strict with what each line would do.
I don't think it necessarily implies confusion regarding the scope because you define that and as the code changes it may be more or less necessary to add or remove braces.
Generally, when the code to be executed is significantly complex, it is preferable to send that code to a separate method.
Again, I think it depends exactly on what you want to do and what you think they can do with that code. As for 'using', in many cases I have preferred to use braces since throughout the execution of the normal scope the instantiated resource exists, there are other times that I have preferred to send all this to a separate method due to its complexity.
It all depends, I think, on the guidelines in each project.
As a C# programmer, I hate using aliases and in all my personal projects I use System types, however in my day-to-day work I use int, bool and long, even string, because they are the guidelines of those projects.
Thanks! Love this series
I would choose the "Bad" example any day! Also, I would leave empty line before and after "for"
Hey Nick. How did you surround the line so quickly in 5:51 in Rider ? What keyboard shortcut did you use ?
Long ago, I used to personally like his recommended approach but only if I have just one line in that scope, then I remove the braces.
Now, I love the braces because I started enforcing code rules with editor config.
I agree with you, the braces makes the scope clear and more readable.
Thanks for sharing, Nick.
My opinion is that it's just a habit to a pattern. Both are readable if your eyes get used to.
If you work for a while with Python or Smalltalk you get used to more compact code and your eyes start burning when getting to C#. But after a while you get used to C# too.
For projects I would advise discussing which pattern to use within the team: compact, extensive, middle point. It's actually more important to agree on a style in a team and follow it than the style itself, to avoid the risk of having a high style entropy.
No braces just so I can show my family, “look at this super complex hard to read stuff I do at work… I’m so brainy” 😂
I completely agree with you.
I just remove braces when I'm going to short circuit a method in it's beginning and return in the first few lines.
Let me know your thoughts on this.
The Uncle Bob's post states that he would first extract the inner loop into another function, and then reward him by removing the braces. It has kind of the same principle as avoiding to many levels of identation. Making code look like paragraphs one after another.
In this context, removing braces is not the rule by itself. The sample code is like removing identation inside the loop, has no meaning doing this.
One good reason to keep braces is if you make a search replace and you replace the one inner statement with two statements then the second won’t be in the for loop as expected
It usually depends on the specific function, but I tend to lean toward the "no braces for single-line instructions" if the surrounding code is not messy.
In the example case the two indented for loops don't bother me at all: they and the their final instruction are simple and short enough to convey what they do at a glance. So in this particular case I'd like to save vertical space by not using the braces. I do find it more aesthetically pleasing.
But as other users correctly commented, having a common code standard and the "always use braces" rule really helps when you work in a team on the same project. It bothers my aesthetic sense a little but it surely is not a hill to die upon. :D
Without the braces (in this case) is clearer to me
Sorry ma friend, but u need to go see a doctor, u have problems
I worked in C++ a lot on previous projects, and I've definitely gotten burned by scopes not being clearly defined. It's not as bad in C#, but I do still prefer it a lot. And as some people mentioned below, it makes merging code a lot more robust. The only cases where I sometimes omit scopes is when the only thing inside is a simple return, break or continue.
Not having scopes for loops is especially careless, since having a clear idea of what is looping and what is not is generally essential for properly understanding the flow.
When I was first starting out I felt really cool doing the indentation stuff. Now I've completely reverted back to using braces EVERYWHERE. Even for stuff like if-guards. If it becomes too noisy to read, then the problem isn't my braces, it's that my method is too complicated. It's a great tool for visualizing the cyclomatic complexity (use this term if you want to sound smart and convince other devs).
So yeah, that's 4 independent lines to do a simple if-check with a throw or return. This is self-punishment but for the betterment of the code quality in general.
I agree 100% - always use braces. One I didn't use them on an if statement. Later I added another line to the condition not realizing it was out of scope. That took a good minute to debug!
We just recently outlawed the second example in our codebase.
No-Braces returns for guard clauses are okay but for(each) loops require braces and ifs also in most cases.
When I began my coding journey, I started with Python, unaware of other structural formats besides its indentation-based hierarchy. It was only when I encountered a C# tutorial that I instantly fell for its organized syntax. To me, the curly brackets provide such clarity to the code. I can glance at a well-structured C# file and immediately discern its organization in terms of class objects. It's somewhat disappointing that C# now permits coding without the curly brackets. I wish Python had adopted C#'s structure instead of the reverse.
Completely agree, the first version is easy to understand for everyone, even for people who don't know C# or don't have much experience.
In addition, using brackets for all these things is good for consistency AND is less sensitive to bugs, but correct me if I am wrong but in C#, brackets can be omitted only if the for-loop has a single statement right ?
So what happens now if you need to add a second statement for whatever reason ? You have to make a change to your code OTHER than just adding the statement.
Granted, I don't think it's particularly likely in this case that you will forget to add them, but who knows ?
I would much rather have my code in a form that can be changed with as little extra modifications as possible. I want my code as consistent as possible, always in the same layout, always visually indicating scope.
If you make what's in the {} as a method, instead of making it multi line not only do you add testability but it does make it way more readable
Definitely no braces, but this is an unrealistically simple example.
Braces give me an extra thing to read without a good reason as there's nothing else in the scope other than this nested loop. I'd rather read & think only about them.
This is not a hard preference though and I'm not consistent about it when I'm writing such stuff myself.
I sometimes use python too and IDGAF about the syntax most of the time.
I like to limit my uses of braces when it makes sense, my issue with the above code is not with or without the braces, it is the nested for loop. I would refactor to have the inner loop its own method that returns a List, that the initial method would AddRange() to its final return. This would allow me to test what is currently the inner loop without having to do the outer loop. It would also make the single line no brackets more readable
Answering your question about which of the two OP's examples I prefer: I would definitely prefer the first one - the one that's "wrong". If I had written it, I would definitely include braces, but I'd also add a blank line after the variable declaration and before the return statement.
what is the cost of braces ? especially when you often need to add some traces inside a loop to log values.. this is so stupid to remove braces...
First one is prim and proper and everyone should be doing it like this.
Second one is only in my own code within a playground project testing something.
Edit: I tell people not to do this because someone else might add code (or even you) and now its not a single line anymore but they (or you) forget to add the braces in. Simple to introduce bugs.
The only time I use no braces nowadays is when everything fits nicely on a single line. If the content of the statement becomes too long, newline + braces it is. Also tend to space out the individual conditions on a one per line basis (given it's more complex than one or two simple comparisons).
Readability is essential for speeding up understanding of a piece of code imo.
You shouldn't do something because Uncle Bob says so. However, for me the merits of removing unnecessary braces outweigh the merits of not removing them:
If it was Rust, JS/TS or any other language where it's typical to put the starting brace on the same line, this wouldn't be such a big deal. But in C# you typically do a newline before brace.
This just ends up becoming noise. If you have a small file with a number of one-liner if / loop / using blocks, a huge chunk of that small file is newlines for the sake of braces. If you have some legacy code with thousands of lines, it's probably going to have lots of ifs, loops and usings, which means there's probably going to be a lot of one statement code blocks. I've seen it all, methods with hundreds of lines of all sorts of one statement if blocks. In large files you could save hundreds of lines if you omitted braces in one statement if / loop / using blocks.
For the people who end up creating bugs by removing braces, I don't know what you're doing to be honest. I'm pretty sure all the tools and IDEs these days offer some kind of formatting as you type. I've never in 10 years of programming professionally seen this be an issue.
This is an issue that often goes hand in hand with the debate about implicit / explicit typing. Var is king, baby!
I usually remove braces when methods are one-liners so I make them lambda expressions, or if there is a single line in if statement or a loop and not much else going around that. It really depends for me how trivial the code is.
7:20 Nick, people actually already using your name :), but I think this is because many of us really appreciate your demos and explanations. Good job!
I used to not add braces for one liner like example 1, but i would at least put a white space before result. As time moved on, I think my problem is that I dislike braces on a line by itself. I dont mind for methods but i do mind for control flow statements.
I always use bracers with loops. Seldom with using or if.
With an if i like the condensed
If this
Then that
They bellong together, the extra spacing take away from that.
For a loop i like to see the scope.
For usings i use scope only if the scope is important. Most often im happy with letting them scope out at the end of the method like all other variables.
Love yield!
I sometimes include braces for single-line nested content, unless it's a simple statement like return, break, continue. That's one of the few exceptions where I do not include braces.
I will only drop the braces after an if-statement if the guarded statement is return (and only for void methods), continue, or break.
I am pro brace.
I prefer the consistency over the brevity. To me it's simpler and easier to read if every if and every loop are the same and you don't have to think about sometimes they do and sometimes they don't.
The one exception to that is one line null checks/guard clauses.
It depends on the situation, in this specific case I would probably use the brackets.
For example I don't use brackets if I'm doing an IF check inside a for loop that only thing it does it continue because I find it more readable.
if(x > 10)
continue;
And to add more to it, in this specific example of 1 line code that only does continue I keep it in one line since it's pretty much like reading English and I find it super easy to read.
if(x > 10) continue;
It depends. I lean towards braces in most cases, but I am a fan of omitting them for simple IF statements with one line that exits the method (e.g., throw or return). For anything else, I use braces because, yeah, I think it's easier both to read and to edit. Probably the better advice is to limit the NESTING of braces. Lots of levels of braces is certainly a code smell that begs for refactoring into separate methods.
I prefer the first option. I always want to show intent as clearly as possible. By having { } it's clearer that I intend to have everything within the braces execute as part of the for loop. If I don't have those it would be trivial to break that code in a way that would be hard to detect. If I were to insert a line of code between the for statements and not enclose everything in { } Now, the new line of code executes N number of times, but the second for loop only executes one time instead of the N number of times.
Braces always for conditional/loop etc. regardless whether it’s a single line or not!!! It makes the code more readable and more maintainable, especially if it becomes necessary to change that single line block of code to one with multiple lines.
I think advice to remove “unnecessary” braces is not necessarily bad advice in and of itself, depending on how one distinguishes “unnecessary” vs “necessary”. For example, it’s probably a good idea to remove truly redundant braces, such as pairs of inner braces embedded immediately within outer braces, and other such cases where they serve no useful purpose; but if readability and maintainability are considered to be “necessary” then one can still add braces even for single line blocks while at the same time removing truly redundant braces in other cases like the ones mentioned above.
My advice to my juniors and intermediates, is write code that other people will be able to understand. Imagine having to debug a production issue but before doing so, you have to spend time trying to decipher the code and understand the scope. Pain in the ass. Keep it simple and readable.
Lmao, this one got so heated near the end. I was laughing harder and harder after every sentence
I don't often have loops as using LINQ, but I try always invert IF statements with early return to reduce nesting and often don't use braces if I have only one command inside. In this nested loop example it maybe looks uglier but, come on, it's almost no difference to me.
The other problem with the one-line "for"s is that if you add a second indented line after the "factors.Add(divisor)", it becomes a very difficult bug to spot, since that line is visually inside the loop, but in reality, it's outside. (And before someone says it, I've seen a few programmers who leave auto-formatting disabled, so the line would stay indented.)
I only omit braces for early returns. I feel that the scope designates "something happens in this block and then we continue", where early returns are an exception to this idea in that they exit the parent scope, so the lack of braces makes a bit more sense when conveying the logical structure.
I almost always use braces with one exception being if statement ending in a early return from function in which case I perform return in the same line as if statement without any braces.
I can work with both, it depends a lot on the rest of the code. BUT make sure to use one style, do not mix with and without bracers.
For the example, its short so even without bracers its not very hard to read. But if I have multiple nested I usually (as in almost always) use bracers so that its clear thats its actually two (or more) nested loops.
I also often break out nested code into separate functions, especially if I can name the function in a way that explains the code better and makes following it easier.
nested code is always harder to read and can make it a lot harder do follow. Yes for some cases breaking out functions are impractical and nesting things is better code.
For a single level like an if or loop with no nested parts I sometimes leave out the bracers, and for really short ones I even have the content on the same line, like if you have multiple guard clauses in a row, the content it almost always just a return or throw and the important part is the condition that should be easily readable.
And your right, the "reason" is bad. I think clean code is a good book BUT you should not take it as facts, its one way to work with code and you should understand the advice and then decide if you think it fits your case.
Just pointing to someone and claim they are the truth is bad and especially since programming is an area that changes so much all the time :)
I started out with basic with line numbers and the good practice was to use line numbers if tens, 10, 20, 30 so that you could easily inject lines later if needed, I do not se many using that today even IF you could use labels on every line and that way recreate the line numbers :P
I actually prefer no braces for 1 line, because tabulation already denotes scope and VS does that automatically, or can autofix it with one shortcut.
But, remove braces when they are, say, 2 lines inside. What does he want? Extract inside of loop to method everytime?
So, I don't really think braces make code harder or easier to read in most cases. To my brain, they are just syntax tokens that represent a scope, so I basically don't even see them when reading code. However, they do add extra blank lines between the code you're trying to read, and therefore you can see less code at any given time if you have lots of unnecessary braces. Even in that nested loop example, I do think I actually prefer no braces, but I would add some whitespace lines before and after the nested loop. However I also think eliminating all unnecessary braces is probably not a good idea.
For example, if you have a nested loop, and the outer loop doesn't need braces, but the inner loop *does*, that can be harder to read if you only include them on the inner loop. That's just one example, but there are plenty of similar nesting situations where having the unnecessary braces is better, in my opinion.
Usually I drop the braces if I just have a single line, because it makes it easier for me to read. But if it's a nested loop like that or nested if or anything then I still use the braces to show the scope and make it not look like a blob. So in the case of this video, I prefer the version with braces.
With the braces is infinitely better for many reasons.
1) I have a visual impairement and the braces help in readability. Allman style is even better as the braces are aligned.
2) If in the futur we need to modify the code, already having the braces means less noise in the git diff.
I used to do no braces and then I would run into issues where I would comment out the line in the if block thinking it would just not run that line much like if there were braces.
...Now the line below it is in the if block >_
Another reason for including braces is that if you now add another line of code in that scope and forget to add braces, you are going to introduce bugs because only the first line will be within the scope. Usually your ide will alert you but not always and some people might not understand the error message etc.
I sometimes opt to use no braces on a very simple if statement, but that’s the exception.
For, foreach, while, and all those automatically get braces for me no matter how simple they are.
Especially in the example given, having nested for loops, it looks ridiculous not having braces on at least the outer one.
I was always on the fence with most examples like for loops and if statements that are multiline.
Right now in my opinion, if a block is 2 lines, then I will use braces.
But I do remove braces when it is short enough to be 1 line, which is mostly stuff like:
if(condition) continue;
if(condition) break;
if(condition) return;
if(condition) throw new XyzException();
if(condition) counter++;
Stuff like this is always one line and without braces for me.
I detect these extremely quickly now and I think something like this looks extremely awful:
if(condition)
{
continue;
}
I totally agree that using braces is a superior way. They remove any ambiguity from the code where the scope is and makes the code more readable.
Moreover, when using braces one can also collapse the code in Visual Studio, so one can quickly hide the whole content inside e.g. foreach loop.
The only place where I prefer not using braces is when there are very short checks which then lead to returning from the method or breaking the loop execution, e.g.
if (a == 1) return;
if (a == 2) continue;
if (a == 3) break;
In this case the code is easy to read, especially because return/continue/break are highlighted.
I mostly use braces to remove any ambiguity.
For example:
if (something)
if (something_specific)
do_something_specific();
else
do_something_random();
Where does the "else" part belong? The first "if" or the second one?
VisualStudio says to the second one.
When you've crafted thousands of lines of code, encountering something as diminutive as this can't help but bring a smile to your face. In the vast expanse of an enterprise-level project, a method as concise as this would likely go unnoticed, akin to a single drop in an ocean of complexity
Readability aside, removing braces can also create ambiguity in how the code is interpreted by the compiler. Consider..
if (condition1)
if (condition2)
code
else
more code
Ignoring indentation, which if does the else get connected to?
Here is the case where I prefer to avoid bracers:
if(true)
{
//do some work
}
From my point of view this one is better:
if(false) return;
//do some work
it comes with experience I suppose, when you look on code wider than just on lines of symbols.
I was on bad side far ago and thought less lines is better.
extending, supporting, refactoring the code base on my way I came to braces even for one line.
it keeps more fresh air for further modifications of code, less changed lines in pull-requests, determine the functional block obvious, code looks more structured and so on like as you said
many benefits vs just a one, even somewhat dubious
Since this does not in any way at all affects performance either way could work. To make the codebase look consistent, a team could agree on which approach to use. I personally prefer the single line approach but the downside I find is when I have to add additional statements that then require the braces there is that extra step of wrapping the existing one line in braces first then add the additional code.
I agree with the "Remove Braces From Your Code Now!" Dude, as I also remove the braces where I only use one line. The best case, I don't have nested code, but when I do, the braces do no good and the readability comes from the naming, so you can read the code as if it is just text. But for example:
if(someClass is not null)
{
someClass.Dispose;
}
someClass?.Dispose();
or
foreach(var data in dataList)
{
anotherList.Add(data);
}
foreach(var data in dataList)
anotherList.Add(data);
or even
if(someClass is null)
{
someClass = new();
}
someClass ??= new();
But I also have this in my code where I haven't found a cleaner solution and just put it in another method to make it cleaner where I use it
private void ReplaceComponentTypeReferences(Assembly assembly)
{
foreach (var ignoreAssembly in _ignoreAssemblies)
foreach (var ignoreType in ignoreAssembly.GetTypes())
{
foreach (var type in assembly.GetTypes())
if (type.FullName.Equals(ignoreType.FullName))
{
if (type.IsSubclassOf(typeof(Component)))
ScriptSystem.Replace(ignoreType, type);
else if (type.IsSubclassOf(typeof(EditorComponent)))
EditorScriptSystem.Replace(ignoreType, type);
}
}
}
and there the additional braces wouldn't do any good, they would just add 8 lines of unnecessary lines of formatting
I usually go no braces ONLY if the scope contains one, very short line or one instruction. For instance I make guards with no braces. The inner for loop I would have removed the braces, but not from the outer one, so that it’s clear what’s going on inside.
I normally always use Braces, but if I use a one line if or a method that only returns something, then i remove the braces. For me for such short methods or ifs it looks cleaner, but if someone from my team prefers to use it with the braces then he should do it.