|
Languages like VB.NET - where they realize the user cannot comprehend the beginning and end of a statement lest it be spelled out for them.
You don't have to remain left-out, you know! Just start to program in a language the doesn't presume your IQ consist of one or two digits.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "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 |
|
|
|
|
|
Readability is one reason. There is another one in my opinion, extensibility. We never know whether we'll need to insert a second statement, considering that programming (and thinking) is an iterative and adaptive process.
Best,
Jun
|
|
|
|
|
Jun Du wrote: extensibility
Hahha  Yeah, the fact that we're writing our code in stone stops us from adding a pair of braces around new block of code.
And if someone has trouble remembering to add braces after inserting new lines should consider changing career.
|
|
|
|
|
It's not that someone has trouble adding braces concerns me. That is taken care of by the compiler. Some developers tend to closes up their code (and mind) at the first iteration of implementation. As a side note, in reality, I didn't find many cases where one statement is enough.
Best,
Jun
|
|
|
|
|
Jun Du wrote: Some developers tend to closes up their code (and mind) at the first iteration
of implementation.
What a crock of horsesh*t.
Jun Du wrote: As a side note, in reality, I didn't find many cases where one statement is
enough.
Apparently we're not living in the same realities then.
|
|
|
|
|
Mladen Jankovic wrote: And aren't we suppose to consistently try to minimize amount of code we write?
no.
|
|
|
|
|
Good thing we're not working togather.
|
|
|
|
|
Mladen Jankovic wrote: aren't we suppose to consistently try to minimize amount of code we write?
Yes, but only if other things are equal, i.e., we don't decrease readability, maintainability and reliability.
Now, as it happens I don't consider the omission of parentheses is that big a deal. But if others feel it decreases readability and maintainability then that would trump "less code is better."
Kevin
|
|
|
|
|
I always wrap single line statements.
I also always put them on a seperate line to make it easier to read.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
For me, it's not a readability thing - though that helps. I find it difficult to read this correctly:
if (aVariable > anotherVariable) yetAnotherVariable = 6;
aTotallyDifferentVariable = 7;
But the main reason I do it is because I have been bitten by problems caused by editors that don't auto-indent before:
if (aVariable > anotherVariable)
yetAnotherVariable = 6;
aTotallyDifferentVariable = 7;
Is not the same as
if (aVariable > anotherVariable)
{
yetAnotherVariable = 6;
}
aTotallyDifferentVariable = 7;
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
Heck, why don't you use few more pairs of braces, make a point and let it be more obvious:
if (aVariable > anotherVariable)
{{{{{
{{{{{
{{{{{
yetAnotherVariable = 6;
}}}}}
}}}}}
}}}}}
aTotallyDifferentVariable = 7;
|
|
|
|
|
Let's not get carried away - 5 + 5 should be enough!
Have you seen what VS does with your code when you cut'n'paste?
void x()
{
if (aVariable > anotherVariable)
{
{
{
{
{
{
{
{
{
{
{
{
{
{
{
yetAnotherVariable = 6;
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
aTotallyDifferentVariable = 7;
}
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
cfff! cfff! cfff! cfff! pffr! pffr! cfff! BOOOM!
|
|
|
|
|
Yes, that is a good point. To me readability includes easily being able to tell what the code is going to do  
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
|
A 1975 paper to justify your answer? per-lease!
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
Have a bit more patience with newbies. Of course some of them act dumb -- they're often *students*, for heaven's sake. -- (Terry Pratchett, alt.fan.pratchett)
|
|
|
|
|
Meh, everybody knows all programming wisdom comes from Lisp, invented in 1958.
|
|
|
|
|
I'll do this:
if (condition) DoSomething(); but this is an abomination:
if (condition)
DoSomething();Also, if any part of the statement requires braces, then the entire statement uses braces, even if it can be done on a single line.
We once debugged a problem caused by someone inserting a line like this:
if (condition)
InsertedSomethingOrOther();
...
EvenMoreStuff();
DoSomething()The statement originally had braces, and during their editing they'd removed them at some point.
I'm pretty sure the body will never be found.
Software Zen: delete this;
modified on Monday, May 16, 2011 10:02 AM
|
|
|
|
|
Gary Wheeler wrote: if (condition)
InsertedSomethingOrOther();
DoSomething()
But how that can ever be a problem? Just look at the indentation - unless you are coding in Python, the indentation screams at you.
|
|
|
|
|
The call to DoSomething(); is now unconditional, instead of being part of the if statement.
Software Zen: delete this;
|
|
|
|
|
Yes, I know what you mean. What I am saying is that the error is so obvious that I can't imagine it ever being a problem.
|
|
|
|
|
Unfortunately, the original DoSomething(); was indeed a method call, and the inserted junk was a couple dozen lines of code.
Software Zen: delete this;
|
|
|
|
|
I believe you, but in 15+ years of professional software development (+ more as a hobby) with C-like languages I have never run into issue with that kind of bugs. I've seen ones with a semicolon after while, and even today I often miscount parens or even forget a semicolon here and there, but in your example the indentation just shouts in your face that something is wrong.
|
|
|
|
|
A contributing factor to the problem was that several hands had been working on this particular project. Brace style and indentation were not consistent, which meant that the two missing brace characters were less visually obvious than you might expect.
I was involved in finding the problem, because my application communicated with the service in question. The code itself was not mine, fortunately.
Software Zen: delete this;
|
|
|
|
|
I believe everything you outlined should be pounded into every new C/C++/C# student until it's second nature.
if (condition) DoSomething();
I used to shun this but now use it for strings of similar, ultra simplistic ifs. It looks clean, and if used in the right place is staggeringly obvious what it's doing. Not, as I have seen:
if (condition) x ? y : z;
And x, y and z are greatly abbreviated here. *shudder*
For the other cases, I type both braces as part of typing the if (or for, or whatever), before I type any of the contents, regardless of if it's only 1 line.
He said, "Boy I'm just old and lonely,
But thank you for your concern,
Here's wishing you a Happy New Year."
I wished him one back in return.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
