|
Indeed.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I agree
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Agree. 8 lines is required, even for cases that could have used a simple ?:, but beyond 8 lines is a waste.
Many times I have met programmers who really oppose ?: and insist that e.g.
ticketClass = (age >= 16)? adult : child; must be written over 8 lines as
if (age >= 16)
{
ticketClass = adult;
}
else
{
ticketClass = child;
} If their productivity is measured in number of source code lines produced, I can see the justification for it, but that's all I can think of
Another funny thing is that those who oppose ?: frequently are proud of their creations in regular expressions.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Or even worse ...
if (age >= 16)
{
ticketClass = adult;
}
else if (age < 16)
{
ticketClass = child;
}
|
|
|
|
|
You still do not handle the null case.
True story:
A friend of mine, living here in Norway, is a US citizen. She was pregnant, and planned a recreation trip out of Norway, 3 months after the expected time of birth, with her baby. Even a baby needs a passport. If you live in Norway and apply for a US passport, it can (or at least could in those days, this is 35+ years ago) take half a year to get through the paper mill.
The parents didn't want to know the sex of the baby before the delivery, so when they applied for a passport for the yet unborn baby, they could not state its name. They could not state its birthday. They could not provide a photo of the passport holder. Yet, the US passport authorities did issue a passport to a person of unknown sex, unknown name, unknown birthdate, with no photo or fingerprint.
I am honestly surprised that none of the systems handling that passport application went into a fatal exception Or maybe they did, and it had to be debugged before the passport could be issued. Maybe, 35 years ago, US passports were essentially handled through manual procedures where exceptional conditions were handled by human brains. I am not sure that all of the fully automated passport handling systems we are using today would be able to handle that passport without stumbling and falling over.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: this is 35+ years ago ... surprised that none of the systems handling that passport application went into a fatal exception
That long ago might not have been a system. Might have been a person.
Could also just be a special case that they handle.
|
|
|
|
|
Yuck
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
It could be worse, it could be raining:
else if(marks > 80 && marks < 95)
{
}
else if(marks > 70 && marks < 80)
{
}
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Yes, I have seen that a few times in QA.
|
|
|
|
|
I think the ternary operator gets a bad rap (although somewhat deserved) because it so often gets abused, particularly, I think, because it's so easy to abuse.
Just today I caught myself chaining 3 of them together, and then luckily confused myself and rewrote it using if statements.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
you forgot one...
ticketClass = age switch
{
>= 16 => adult,
_ => child
};
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
|
|
|
|
|
I like things more compact
if ( expression ) {
} else {
} I think that's the way it's done in K&R, in which case I'm in good company.
But putting the opening brace on the first line of a function definition annoys me intensely e.g. Don't:
int main(int argc, char *argv[]) {
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
yeah, the brace on the same line makes me want to puke.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: yeah, the brace on the same line makes me want to puke. I follow the same rule when I write plain prose. If I want to write something that is not absolute but associated with some condition, I enclose the entire conditional part in braces and put on separate lines. Such as
If (the rain stops), I told her,
{
let's take a walk in the park.
}
but if it keeps raining,
{
I want to lit the fireplace and fetch a bottle of wine from the basement
} When I write the prose this way, it is so much easier for the reader to foollow the structure of both the conversation and the actions.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
agreed. On the other hand, I am not a religious zealot of braces. It really comes down to being able to debug - meaning putting a breakpoint on something I want to check or might need to check. Simple logic, I like (love) the ? option.
Don't get me started on prefix or postfix ++ or -- operators in if statements. There is a special place in coder hell for that crap.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Wholeheartedly agree!
Having the braces on separate lines makes it so much easier to determine where the then/else clauses begin and end. Lining them up vertically at each indentation level also means you can easily see what goes with what, such as:
if (expression)
{
// then result
if (other condition)
{
// Other condition then result
}
else
{
// other condition else result
}
}
else
{
// else result
}
I really hate code that puts all the opening braces on the if (expression) line, or the "else" line. Programmers who don't believe in clarity of their code should be banned from the practice.
Don't forget -- comments can also help a lot in improving clarity.
|
|
|
|
|
Norm Powroz wrote: Having the braces on separate lines makes it so much easier to determine where the then/else clauses begin and end. You have indentation for that, don't you?
If you indent neither of the braces, they do not enforce the indentation, but blurs both the indentation and the keyword causing the indentation. If you indent both, the keyword is 'revealed'. And the block is extended by two two lines, making it more prominent.
I think that making 'the indenting keyword' more visible (by avoiding the blurring opening brace immediately below it) is a good thing. Indenting before the opening brace is logically inconsistent - so the brace should be un-indented, at the line of the if / while / ... . Also, when you read e.g. an if, and the line ends abruptly, with no explanation, you should rather include the brace to indicate: There is an explanation - this brace tells that a block is following!
The closing brace on a separate indented line ensures that the indented block is at least two lines long. That should be enough for everybody, to make sure that the block is easily identified.
I think un-indented braces blur the indented block, rather than enforcing it as it should.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Second style was invented at the Department of Redundency Department.
|
|
|
|
|
|
BernardIE5317 wrote: You can say that again. Second style was invented at the Department of Redundency Department.
|
|
|
|
|
BernardIE5317 wrote: final statement else throw who_the_heck_knows_what_happened
In such cases, would a switch case statement be more appropriate? I mean when there are more than 2 choices.
|
|
|
|
|
Thank you for the thought provoking suggestion. Please consider per below.
if(a==true && b==true) {...}
else if(a==true && b == false) {...}
else if(a==false && b == true) {...}
else if(a==false && b == false) {...}
else throw who_the_heck_knows_what_happened; // just for the heck of it
|
|
|
|
|
I do hope that the "==true" and "==false" are not meant literally! A programmer comparing a logical expression against "true" or "false" have not understood what is meant by a logical expression.
I wonder how many of those programming that way also speak that way! "If you have a moment to spare is true, I want a talk with you", or "If the door is unlocked is false, you'll find the key under the door mat" - noone that I know speaks that way. I have met a few programmers who program that way, but I never heard any of them speak with "is true" or "is false".
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
May I please inquire how else does one evaluate a logical expression in C++.
One can write if(a) or if(!a) .
But these perform the same function as if(a == true) and if(a == false) .
if(I do not understand your meaning == true) I kindly request clarification.;
|
|
|
|
|
Similarly, "if the door is locked" perform the same function as "if the door is locked is true".
In speech, noone that I know of includes the "is true". So why do you program as
if (doorIsLocked == true) ... rather than
if (doorIsLocked) ... I see no reason for or advantage of creating a more complex logical expression, adding a second, redundant element. Both "doorIsLocked" and "doorIsLocked == true" are logical expressions, the second one just more complex than it needs to be. (Hopefully, the compiler is able to optimize the redundant element away!)
If I program a test like
if (x < 10 && x < 20) ... all programmers I know would point out that it is redundant to test for "x < 20" if you already have tested that x < 10.
Adding an extra element a logical expression, to see whether a true "a" is equal to "true" (or that a false "a" is different from "true") is similarly redundant. The logical "a" expression is true or false, all by itself!
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|