|
In my early years, there is no specific standard for this. It's totally depends on current mood.
But after years and projects, sooner or later, I realized that doing it with markers will make the code block more maintainable, less bugs, more easier for expansion, more readable by human, less confusion. It makes life more easier at later time whenever I needed to come back to debug the code block.
In quite a number of times when I came to the same block, I needed to re-add the markers for performing further additional coding lines and variables for other logic test, etc. So, next time whenever I code this part, I'll always add the markers, this is because I know there's a high percentage that I will still need to re-add it in future (especially while debugging).
|
|
|
|
|
The problem with not marking the code is not with the original authoring but later in the life of the code. Usually, less experienced people are put into support roles and they sometimes do not look carefully at what they are doing. They add another line to the if block but do not notice that there are no curly braces. They then show up complaining that your code does not work right at which point you must take the time to look at it and, hopefully, see the lack of braces. You can handle this several ways: One, a learning experience for your greenbean or Two, a chance to mercilessly ridicule the less experienced. Of course, there is always three, you don't notice it yourself and end up looking like a jackass.
|
|
|
|
|
It seems these days people are somewhat confused about the difference between compact and clear. They'll jump through 10,000 hoops to save five keystrokes, and then immediately use 300 more keystrokes than they require because they're not quite sure of the objective. In the case of bracing - in all cases, the rule is simplicity itself. Always brace. Why? Because it's really easy to lose track of the nesting level. If you do that, then you've got a bug that's hard to find and gives weird results. If you always brace, even a *program* can figure out the nesting levels and highlight them. Remember, you're not writing this code for yourself. You already know what you're thinking. You're writing it for the person who has to try to fix it five years from now who has never heard of you. So help them out.
David Wright
|
|
|
|
|
To be precise, I don't use block markers with single-statement, single-line blocks. I do use block markers with single-statement, multi-line blocks. I almost always heavily favor whatever has better readability and that generally means favoring less clutter. I also use lambda syntax for single-statement, single-line methods in C# 
function blah() {
if (someBool)
doSomething;
if (someBool)
{
doSomethingMethod(
arg0,
arg1,
arg2,
arg3
);
}
if (someBool) doSomething;
if (someBool)
doSomethingMethod(
arg0,
arg1,
arg2,
arg3
);
}
modified 22-Oct-21 15:09pm.
|
|
|
|
|
I don't use it if I am confident it will not grow, such as in a finally block to check and close open resources.
Otherwise I will use braces, even for single line statements.
|
|
|
|
|
I've encountered too many bugs that resulted from the incorrect editing of code not blocked with block markers.
|
|
|
|
|
Anyone use a language other than Python? Curious to know if there are any others.
(I selected this btw, since I pretty much do just Python.)
Cheers,
Vikram.
|
|
|
|
|
Haven't done any for years, but iirc, VB has no braces [obvs] and forced:
If a = b Then
Thing()
End If
veni bibi saltavi
|
|
|
|
|
Once upon a time (1/t), I was coding Fortran IV. My memory is failing, but I am quite sure that it had no sort of block markers. Unless you count the line label in the left hand column as an end block marker.
We managed to enforce a rule about loop indentation. Some people were strictly against that as well: Code is supposed to start from col. 7!
|
|
|
|
|
About the only time I don't use block markers for a conditional is if I use a ternary operator (infrequently used).
|
|
|
|
|
This sounds like an interview question!
|
|
|
|
|
I generally write code with block markers and multiline, even if it's a single statement.
But before the final test and check-in, I often run the code through CodeMaid to ensure the formatting is standardized and its default settings take them out.
|
|
|
|
|
Change the settings then! (Is possible?)
|
|
|
|
|
Actually, I'm quite happy for CodeMaid to take them out.
|
|
|
|
|
#BEGIN
#END
Is that the best they can do?
What about when I share a block of code on social media and all the indenting whitespace is clobbered?
|
|
|
|
|
Specifically if opening braces get a line to themselves. If they do I generally don't bother, If they go on the previous line I always do because missing braces are much easier to overlook that way.
if (foo) {
Bar();
Baz();
vs
if (foo)
{
Bar();
Baz();
The mismatched { is much more apparent in the latter than the former IMO.
So yes in Java/Javascript, and generally not in C#. I haven't done C or C++ in a long time; but would follow whatever style guide we were using says to do because consistency is king.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Where I work, the team decided to use block markers in all cases. I'm ok with it, but on personal projects I only do block markers on multi-line code blocks.
|
|
|
|
|
It's too easy to add a line to a conditional clause, and forget to wrap the 2 lines with block markers. Wrapping everything (even single lines) avoids this sort of bug.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Absolutely agree & clang-tidy ensures that if I forget, I soon get reminded...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Daniel Pfeffer wrote: It's too easy to add a line to a conditional clause, and forget to wrap the 2 lines with block markers
I'm in the "it depends" category, and I don't ever recall this bug happening to me. Lots of careless bugs, but not this one.
|
|
|
|
|
Lucky you...
It has made me spend some hours looking for the ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) ing place until a :BIGFACEPALM: came 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Indeed, I thought exactly the same just before reading your post ... 
|
|
|
|
|
Every code block must be enclosed in block markers.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
One of the things I miss from Pascal: A statement is a block. A block is a statement. For each (early) revision of the C standard, I was hoping for this to be incorporated into C, but in vain.
For many years now, zillions of lines of code have been written under the assumption that a statement is not a block is not a statement. It must be well above twenty years since I lost my last trace of hope for this change to be made.
|
|
|
|
|
is our coding standard. It has proven to avoid bugs and make maintenance easier.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
