|
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.
|
|
|
|
|
trønderen wrote: Religious freedom is the freedom to say that two plus two make five.
Incorrect. Two plus two making five is provably incorrect. Religious freedom is the freedom to believe things that cannot be proven.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Religious freedom is the freedom to be irrational. If you reject all irrationality, then you reject religion. We cannot forbid irrationality and still claim that we have full religious freedom.
Using "two plus two make five" as an example is a way to make the irrationality (very) explicit.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Just noting that the semantics of how a logical expression is resolved in C++ is different than in C#/Java.
So the following is valid in C/C++
int v = 0;
if (v) {}
else {}
Because of operator overloading in C++ (to be fair it has been long time since I did this) I believe there can be situations where one must explicitly use the following. Leaving it out at a minimum might lead to a compiler error. I can't visualize a case where it would not lead to a compiler error but might be one and then it would lead to a different and incorrect result at least compared to the code below.
if (p == true) ...
|
|
|
|
|
Ah, the benefits of modern languages.
Waaay back in the 90s, using ANSI C (I was using VAX C and DEC C) the "guru" who had first designed the system, had defined TRUE as (0==0) and FALSE as (!TRUE) -- because these would be unambiguous and correct regardless of architecture (the same code had to work on QNX and DOS).
Personally, I dislike how K&R and ANSI C handle true and false.
|
|
|
|
|
I have frequently seen programmers from India use
if (variable == true){...}
in their code. I really don't understand it.
But to be fair, their variables names do not make it clear that it's a Boolean value. All of my Boolean variables' names are a Yes/No question (IsValid, DoneProcessing, DoUseQuotes, etc.) so it's obviously a Boolean. When your Boolean variables are named poorly (Validation, Finish, Quotes, etc.), then you need the "== Boolean" in order to know what is going on.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
condition ? f() : g();
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Your kind suggestion ? I agree : I still agree;
|
|
|
|
|
My suggestion: Delete every "== true" that you have ever programmed. Delete every "== false" you have ever programmed and negate the logical expression.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I do not understand that code - could you please rewrite it as a regex?
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
As others have said, it depends on the context.
I prefer a ternary operator if I must choose between returning one of two results:
Foo foo = (condition ? Foo1 : Foo2);
For choosing different actions, I prefer the if/then/else style, even if it would be possible to write this as a ternary expression:
if (condition)
{
expressions1;
}
else
{
expressions2;
}
A "cascading" if/then/else is useful for subordinate cases:
if (condition1)
{
expressions1;
}
else
{
if (condition2)
{
expressions2;
}
else
{
expressions3;
}
}
Note that there is angoing debate whether good style requires that one wrap even single expressions in curly brackets. ( {...} }. If is usually not required by the language, but can help clarify the flow.
Note that there are cases where a "cascading ternary operator" can also be useful, and actually clearer than the "cascading if/then/else".
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
In languages were the braces (other other syntax) is not required to block out an IF or ELSE block of code, I have seen many bugs where someone got it wrong, or edited it much later incorrectly. In my code reviews, I enforce having them for all cases because it's impossible to get wrong were the code block starts and stops; there is no interpretation of non-visible cues needed.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
For a "minor matter of style", this got a lot of responses!
I use style#1 if it's clear that all possibilities have been exhausted, and the ? operator if possible.
But if there's a sequence of nested if statements and there's any possibility that not all combinations have been accounted for, I use style#2 with the throw statement after the else. Defensive coding takes very little time compared to that which is otherwise wasted hunting down mysterious bugs.
|
|
|
|
|
But you don't really mean something like?
if (expression)
{
}
else if (!expression)
{
}
else
{
throw(this and that);
}
|
|
|
|
|
No throw here. It's clear that something above will get executed, and the (!expression) is also redundant.
|
|
|
|
|
I will fite you over that code. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
