|
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
|
|
|
|
|
Where do you put the opening brace? Being "raised" on C, I personally hate the Java convention of putting the opening brace on the same line as the condition.
In fact I have started to
if (condition)
{
doStuff();
}in our Java code. There's nothing to be gained by cramming everything together as close as possible.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
I prefer to do it like that too, but if it the rest of the code is already in the IF line... well... I continue to be consistent.
If it is something I start on my own... 100% with markers, in single lines AND in the same indentation as the if and not as the code executed when condition met. I mean:
if (condition)
{
doStuff();
}
AND NOT:
if (condition)
{
doStuff();
}
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.
|
|
|
|
|
There was an interesting article about always using multi line, always using braces and the position of the braces to allow for the best automated merging in SCM systems.
|
|
|
|
|
Yupe, totally agree. More human readable, easy for maintenance, less bug.
|
|
|
|
|
If there is only 1 statement in the if/for/while-block, then no markers, but the statement in the block is written on a separate line, in order to simplify putting a breakpoint on that line.
Easy to put a breakpoint that only goes off if the condition is satisfied:
if (myCondition)
doSomething()
Harder to put a breakpoint (I don't mind jumping into disassembly to find the exact call, but my colleagues don't like it):
if (myCondition) doSomething()
Of course if there is only 1 caller of doSomething(), then you can just put a breakpoint in that function, but what if that function is called a zillion times?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
