|
Explicit delimiters are present also in math, and are a necessary element of it. Want to say that is useless to use them since you can get how the equation goes out of the context? I think not.
From time to time, I see this idea of programming using natural language coming out. Something like: "hey, how good will be if we can program as we speak?". Useless to say I consider this a constrain to programming, which I see as a way more wide world.
Not to mention that people can associate different meanings to the same sentence, and this usually leads to (sometimes fatal) accidents. I don't wish to see this happening in programming. It shall be, in my opinion, something that should not be possible to read in another distorted way (depending on the mood or the context).
Just like math, parenthesis et all are there for a reason; skip them, and you wont pass the exam.
|
|
|
|
|
Sure, and in programming, they may be manadatory e.g. for delimiting a group of statements to be repeated.
But although it is permitted, in math, to write (3 + 5) = 8, but people would ask why you use them. You don't use them unless you want to override a general rule, such as multiplication / division before addition / subtraction. Or in expressions so complex that humans find it difficult to interpret them even if general rules are followed, so you add parentheses for clarification. But those are very rare cases; 99.99% of all real-life math expressions are so simple that the general rules for asocciation is sufficient, and no conceptually superfluous delimiters are used. You won't fail an exam in any school anywhere in the world because you write '3 + 5 = 8' rather than '(3 + 5) = 8'!
Programming in Pascal (and most other pre-C languages) you may of course use paretheses to override general rules such as operator precedence, but for a simple expression such as "if a + b = 8 ..." you don't need it. And the compiler won't barf if you omit parentheses.
The thing with C is that you must write "if (a + b == 8) ...", not to override precedence, not to improve readability by grouping terms, but because the parser is incapable of understanding it unless you give it a helping hand. The computer will barf if you omit them. That is a completely different reason, having nothing to do with the math side of it, nor with human comprehension. It is purely there for the compiler.
Statements in a programming language must be unambiguous; natural language is not. But programming languages other than C have certainly proven that a conditional statement can be unambiguous without enclosing the condition in parentheses.
I read one study, I believe it was done by a British university, where a number of test persons (all programmers) where given a program source code printout, and given a fixed time to study it, before answering a number of questions about the program. The program was the same for all test persons, but one group got it formatted in the spacious programming style, with e.g. 'if', if-clause, 'else', else-clause and maybe (I don't remember) braces each occupying a line. Other groups got the exact same code laid out to resemble "natural text", like 'if (itsRaining) UseUmbrella();' in one line. The study went though a number of programs and layout options.
The conclusion for this study was that the more the program layout resembled "natural text", the better was the comprehension of the program after a fairly short study. Those who read the natural text layout could answer more questions about the program functions, its structure etc. than those reading the loose programming style layout (which probably made the printout three times as many lines/pages). So some aspects of natural text were proven to be valuable, even without making a single change to the source code, only in its whitespace.
|
|
|
|
|
The problem never arise for the language itself; at the end compilers do their job in a quite good way. The problem comes when programmers (and not the original author) join this equation, so that they have to edit whatever is already there. This comes from experience in projects which lasts long and have multiple peoples joining efforts.
Too many time you see something like 'if(itsRaining) UseOmbrella();' becoming like 'if(itsRaining) UseOmbrella(); putOnBoots();' on the same line. The compiler will do it's job, and it will be correct by following the parsing rules, but the final outcome is wrong.
And again, not because the language is bugged, but becouse the human factor in programming has a really high impact factor (and must taken into account). There is a reason why software houses impose code-style and guidelines to programmer, and this is because everyone has it's own style, and this can impact future work done by some other programmers.
Between C peons like me there is the mantra of "always use parenthesis when writing pre-processore definitions".... and there is a reason for that! The if '(a + b == 8)' can assume a different meaning of what you do intend, and this happened to me!
That's why I'm defending my the portability, readability, extensibility of my code by using all the possible parenthesis and imposing an order which is "assumpted" to be correct (even when it's seems obvious), and this approach is giving fruits.
PS: Can you please provide a link to that study please, if you can? I'm interested now! Otherwise citing it does not make much sense, since it seems to be your opinion only, even if you say it's a paper/journal or whatsoever. In this era of fake new is dangerous to do claims such as "there is a study supporting my speech" without providing the source. Especially if your user name is "Member xxxxxxx".
|
|
|
|
|
If I have an if...else situation where both are single line statements I won't bother with braces, but if one is multi line I'll use braces for both to make it obvious they're related.
|
|
|
|
|
Similar here, and it looks neater in that situation. But if using VS I almost always use the "if" and "else" snippets, which auto-add the braces anyway.
Kevin
|
|
|
|
|
In my case, when the if has braces, the else will always have braces, but the if can be single-line, no braces, while the else has braces:
if (someCondition)
DoSomething();
else
{
DoSomethingElse1();
DoSomethingElse2();
}
I also never put the if and the single statement in the same line. When setting-up break-points or when debugging line by line, I don't want the if evaluation and the execution to happen together.
|
|
|
|
|
Star Trek Captains James T. Kirk, Jean Luc Picard, Kathryn Janeway, and MOST IMPORTANT, real-life Captain Chesley Burnett "Sully" Sullenberger III did!
Brace for Impact![^]
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
I try not to, especially if it's just a return statement. But then, when that's the case, as long as the condition isn't already too long, I'll try to put it on the same line.
But then some editors will try to force it on the next line anyway.
|
|
|
|
|
what about conditional operators?
userCanVote = (userAge == 18) ? true : false;
I think this is the example that breaks the mold for everything. I have seen some people do crazy things with conditional operators just to show their "knowledge" of them off.
|
|
|
|
|
Craziest code example I have seen for a while.
I have never heard of a country, organization or anything else were only 18-year-olds, noone else whether younger or older, can vote.
And I have never seen the conditional statement used to select between alternatives 'true' and 'false'. I hope the compiler is smart enough to ignore the conditional and generate code as if you had written
userCanVote = userAge == 18;
|
|
|
|
|
Member 7989122 wrote: I have never heard of a country, organization or anything else were only 18-year-olds, noone else whether younger or older, can vote.
Kevin
|
|
|
|
|
I admin, recently the CodeLen suggest a code piece that I had to do a double look.
return foo ? (foo=new Foo()); or
if (obj is Foo foo) foo.bar();
It's shorter.
|
|
|
|
|
When omitted, it's usually by deletion.
They get popped in by habit - and even if only one statement follows there's no reason to remove them. It's to create a visual convention - you (at least my) eyes have everything grouped for them, indent levels almost always co-re-inforeced with something like:
if(the beginning) {
some_silly_possibility();
}
There are conventions (my own, obviously) for else's, too. Similar for all code-blocks. Even when source is well out of sight you know the beginning and the end (and which/where to insert/delete code and/or braces).
Even if not via some (so-called) standard, it is visually obvious to any onlooker, and that's the real point.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Braces around single line commands. Needed or not?
Survey period: 12 Feb 2018 to 19 Feb 2018
|
|
|
|
|
I mean when I use If..While or For my finger automatically put open and close braces and then start coding between them... 
It same like when I switch from C# to VB.NET code then I put semicolon at the end of the and VB compiler used to give to give me compilation error...
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
koolprasadd wrote: It same like when I switch from C# to VB.NET code then I put semicolon at the end of the and VB compiler used to give to give me compilation error...
Yes, recently I've written a lot of code where I've been switching back and forth between C# and VB. Frazzles the brain!
Kevin
|
|
|
|
|
My rule of thumb, generally, is to put the braces in. On the rare occasions I don't I usually ask myself, "why does this not use the ternary operator then?" In the end, I virtually never wind up without braces.
|
|
|
|
|
ReSharper handles that for me if or else has more than one statement, it puts braces both, else, removes.
|
|
|
|
|
In my experience, ReSharper is a very good tool for enforcing coding standards.
In my opinion, you and your coders should also be aware of the reasons behind the rules. This makes them more likely to be followed, rather than treated as "one of those annoying Management things".
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Ditto
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
The project I started my career as a developer used Resharper to ensure the compliance of most of the coding standards. Two years later the project is rolled out and I switch to another which does not have Resharper, I felt really helpless for the next few days. Good thing I could learn to code without its assistance.
|
|
|
|
|
When it's an error detect and method fail condition, then is short, sweet and single line:
So
if (inputList.Count == 0) return; Or
if (inputList == null) throw new ArgumentException("inputList cannot be empty");
I grew up having to indent code manually, and I learned the hard way that
if (a == b)
c;
d; does not do what it looks like it does, particularly when you edit code and add c or d!
If the brackets are there to start with, it's pretty obvious:
if (a == b)
{
c;
}
d;Modern IDE's make it a whole load easier, but ... good habits are hard to break!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: if (a == b)
{
c;
}
d;
But that's so butt ugly visually distressing!
if (a == b) {
c;
}
The reason I do it that way is to demark the beginning of the block(it's parent) with the end of the block. A further inner one would have all of that bumped in an indent's worth. The idea is for the eye-candy to be very easy to decode, visually. Note the vertical row in your version. Also, I save a line!!!!
But, I'm practical - everyone like their own indents or they'd be using something else.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It's too often that single statements turn into multiple statements and you forget to add braces. So allways add the braces from the very beginning.
|
|
|
|
|
henningbenk wrote: single statements turn into multiple statements and you forget to add braces
I've made thousands of stupid errors in my career so far, but have yet to do that. How is this not obviously wrong, unless you code with Python?
if (something)
do1();
do2();
In fact most compilers will issue a warning for that nowadays.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
