Expressive or verbose syntax?
-
Judah Himango wrote:
Yes, it is more verbose, but it is also far clearer, especially when you have long/confusing if statements or long method names. Verbose code isn't always bad, IMO. You've got to have a balance to not overdo it, but still keep things readable, maintainable, and concise.
I personally don't like "inline if then" statements like your first example, but think that adding the line feed and tab
if (someBoolVal)
DoSomethingWithBlah(x, y, z)strikes the right readibility/verbosity balance without needing the extra braces and lines. Unlike your second example, I like the braces (when I need them) on the same line as the
ifconstruct, and never use them if there's only one statement in the "block" (if,using,for,foreach, whatever). What I really hate seeing is this pattern:if (someNum == 1)
return true
else
return false;Just do this, damn it:
return (someNum == 1);
Brief and readable. Perfectly clear. Even worse is testing booleans to set the value of other booleans:
if (someBool == true) // Explicit "true" test too verbose already, IMHO
someOtherBool = true;
else
someOtherBool = false;Rrrrrrrr. It makes me think that the original dev never stepped back and thought about what their code was really doing. That they were just typing, rather than coding. Anyway, your mileage may vary. Have a good new year everyone... Sean
You know, Sean, I struggled with this for about a year. I *always* did
if (someBoolVal) Something();
After seeing that this gets ugly with long if statements or long method names, I went to the indented line below.
if (someBoolVal)
Something();This worked, but I was always unsure what to do with else statements. I could go
if (someBoolVal)
Something();
else Otherwise();or I could go
if (someBoolVal)
Something();
else
Otherwise();For some reason, I always thought the latter was kind of ugly. I ended up switching to
if (someBoolVal)
{
Something();
}
else Otherwise();Feeling I was being inconsistent between ifs & elses, I decided on going full out with the braces.
if (someBoolVal)
{
Something();
}
else
{
Otherwise();
}This way I was consistent and easily readable, although verbose. I think ultimately what it comes down to is personal preference. As long as you're consistent, I try not to let other developer's code styles bug me. We have one developer who always does
bool localVar;
localVar = GetSomething();
When touching his code, I'm always tempted to change it to a more concise
bool localVar = GetSomething;
but I try to stop myself and let it be. :-) I agree with you on the return thing. I always find
return myInt == 2;
more intuitive and concise than writing extra booleans just to return those later.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Bought a House! Judah Himango
-
Actually, I prefer the braces myself, because they're quicker to type. What WOULD be cool, though, especially with how smart IDE's are getting, would be to have the IDE automatically insert a comment next to the close brace telling you what it's closing. For example:
for (int i = 0; i < 20; i++)
{
if (i == 10)
{
DoSomething();
} //if (i == 10)
} //for (int i = 0; i < 20; i++)Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
Jamie Nordmeyer wrote:
Actually, I prefer the braces myself, because they're quicker to type.
Again, does it matter? A modern IDE is able to automatically insert something like "end for" the moment you type "for".
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Jamie Nordmeyer wrote:
Actually, I prefer the braces myself, because they're quicker to type.
Again, does it matter? A modern IDE is able to automatically insert something like "end for" the moment you type "for".
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
True. VB.NET does this. I'm talking about the syntax editors that manage C style syntax, where everything is wrapped in braces, and as so, isn't always clear what a brace is actually ending. Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
-
In VS 2005, just position the caret at the end of any closing curly brace, and it'll highlight both the ending brace and the opening brace. :cool:
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Bought a House! Judah Himango
Judah Himango wrote:
In VS 2005, just position the caret at the end of any closing curly brace, and it'll highlight both the ending brace and the opening brace
Just checked that out very :cool: (have not had any time to play with VS2005).
ZeePain! wrote:
This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
-
The more verbose they get, the higher the chances of ambiguity! And avoiding ambiguity would further increase the list of keywords and the synactic complexity of the language. I prefer crisp expressive languages. I'd rather say "return 0" than "Mr Compiler, could you please put a zero on the stack and then return control to the calling code, please?" Nish -- modified at 10:28 Friday 30th December, 2005
Nishant Sivakumar wrote:
Mr Compiler, could you please put a zero on the stack and then return control to the calling code, please?
:laugh::laugh::laugh::laugh::laugh::laugh: ___________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] - eMule Server .NET
-
Marc Clifton wrote:
saying "if (x==true)" really is redundant.
With all respect due, it really does provide for clearer if statements. For example, take the more real-life scenario below:
if(foo.Hierarchies.Contains(bar) && !bar.Children.TrueForAll(myPredicate)) DoSomethingCrazy(x,y,z);
Looking at that, I really have to study the code carefully so as not to miss anything. Is it asking whether foo's hierarchies contains bar and the bar's children don't pass the criteria by myPredicate? Is that a true or false? If I miss one exclamation point, the code will be logically flawed. That's my main reason for switching syntax; the possiblity for developer error is greatly decreased using explicit is true/is false flags. Compare this to the more verbose, yet clearer replacement:
bool fooContainsBar = (someHierarchy.Hierarchies.Contains(bar) == true);
bool barMeetsCriteria = (bar.Children.TrueForAll(myPredicate) == true);
if (fooContainsBar == true && barMeetsCriteria == false)
{
DoSomethingCrazy(x, y, z);
}It is obvious to any developer, even one unfamiliar with the code what's going on. You can literally read what's going on, rather than trying to infer it with the previous example. I used to be of the persuasion that the former syntax was better because it was quick & dirty and required very little effort to write. But as I come back to code I wrote several months ago, I find myself trying to infer the purpose of the code from these if statements. When I write the code in a more verbose, yet clearer style, there is no having to infer the purpose of the code or find out what's going on. You simply read, "if foo contains bar, and bar's children do not meet the criteria, do something crazy". I find this far superior. Yes, comments can help infer purpose, but comments are not always present or up-to-date, and are obviously not compiler-checked for logical correctness.
Marc Clifton wrote:
And it can lead to errors, like "if (x=true)"
Actually, if you do this in C#, you'll get a compiler warning saying "Assignment in conditional expression is always constant; did you mean to use == instead of = ?". In the project I've been working on for the last 3-4 years, I've never once made that mistake because the compiler will catch it and alert me should I accidentally type one less equal sign.
Tech, life, family, faith:
Actually, I find the second example harder to read. I have to go back to the bool initialization to figure out what the state test is to validate it, and I have to remember that == takes precedence over &&. And I'm especially thrown off by the use of the () in the bool initializer, where for my personal tastes, the parens around ((fooContainsBar==true) && (barMeetsCriteria==false)) is much clearer. [edit]Actually, "if (fooContainsBar && barMeetsCriteria)" is clearest of all, to me. :) [/edit] In the first example, the only improvement I would make would be to implement a FalseForAny method to avoid the !x.TrueForAll.
Judah Himango wrote:
Actually, if you do this in C#, you'll get a compiler warning saying
Yes, I know that, but I still see people ignoring warnings, just as they don't have the discipline to keep comments up to date. But, back to the issue of code clarity, what I'm realizing is that this is probably subjective. But subjective in an operational sense--I didn't have any problems at all with the first code example, and find the second one more difficult. It brings to light that people comprehend code with different efficiencies depending on the coding style, and that's a pretty critical thing when it comes to working in a team environment. Marc Pensieve -- modified at 12:40 Friday 30th December, 2005
-
Marc Clifton wrote:
saying "if (x==true)" really is redundant.
With all respect due, it really does provide for clearer if statements. For example, take the more real-life scenario below:
if(foo.Hierarchies.Contains(bar) && !bar.Children.TrueForAll(myPredicate)) DoSomethingCrazy(x,y,z);
Looking at that, I really have to study the code carefully so as not to miss anything. Is it asking whether foo's hierarchies contains bar and the bar's children don't pass the criteria by myPredicate? Is that a true or false? If I miss one exclamation point, the code will be logically flawed. That's my main reason for switching syntax; the possiblity for developer error is greatly decreased using explicit is true/is false flags. Compare this to the more verbose, yet clearer replacement:
bool fooContainsBar = (someHierarchy.Hierarchies.Contains(bar) == true);
bool barMeetsCriteria = (bar.Children.TrueForAll(myPredicate) == true);
if (fooContainsBar == true && barMeetsCriteria == false)
{
DoSomethingCrazy(x, y, z);
}It is obvious to any developer, even one unfamiliar with the code what's going on. You can literally read what's going on, rather than trying to infer it with the previous example. I used to be of the persuasion that the former syntax was better because it was quick & dirty and required very little effort to write. But as I come back to code I wrote several months ago, I find myself trying to infer the purpose of the code from these if statements. When I write the code in a more verbose, yet clearer style, there is no having to infer the purpose of the code or find out what's going on. You simply read, "if foo contains bar, and bar's children do not meet the criteria, do something crazy". I find this far superior. Yes, comments can help infer purpose, but comments are not always present or up-to-date, and are obviously not compiler-checked for logical correctness.
Marc Clifton wrote:
And it can lead to errors, like "if (x=true)"
Actually, if you do this in C#, you'll get a compiler warning saying "Assignment in conditional expression is always constant; did you mean to use == instead of = ?". In the project I've been working on for the last 3-4 years, I've never once made that mistake because the compiler will catch it and alert me should I accidentally type one less equal sign.
Tech, life, family, faith:
Ok, be a bit more fair:
bool fooContainsBar = foo.Hierarchies.Contains(bar); bool barMeetsCriteria = bar.Children.TrueForAll(myPredicate); if (fooContainsBar && !barMeetsCriteria) { DoSomethingCrazy(x, y, z); }vs
bool fooContainsBar = (someHierarchy.Hierarchies.Contains(bar) == true); bool barMeetsCriteria = (bar.Children.TrueForAll(myPredicate) == true); if (fooContainsBar == true && barMeetsCriteria == false) { DoSomethingCrazy(x, y, z); } -
That's what IDE (syntax highlight, #region) is for! :rolleyes: Besides, you can always write
} // end for} // end function
} // end classBut you dont need/have to, and that's my point. Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidyI program in VB (have for years) and have hardly EVER had to type 'end sub'. The IDE does it for me.
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things." Jörgen Sigvardsson wrote: If the physicists find a universal theory describing the laws of universe, I'm sure the asshole constant will be an integral part of that theory.
My Blog[^]
-
In VS 2005, just position the caret at the end of any closing curly brace, and it'll highlight both the ending brace and the opening brace. :cool:
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Bought a House! Judah Himango
-
I program in VB (have for years) and have hardly EVER had to type 'end sub'. The IDE does it for me.
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things." Jörgen Sigvardsson wrote: If the physicists find a universal theory describing the laws of universe, I'm sure the asshole constant will be an integral part of that theory.
My Blog[^]
See my other post, for one liners it sucks, no matter if you actually type it or IDE do it for you. With "you have to" I more meant that it is syntax of that language, while with curlies/comments as in my expample its only option, not a must. Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidy -
Actually, I prefer the braces myself, because they're quicker to type. What WOULD be cool, though, especially with how smart IDE's are getting, would be to have the IDE automatically insert a comment next to the close brace telling you what it's closing. For example:
for (int i = 0; i < 20; i++)
{
if (i == 10)
{
DoSomething();
} //if (i == 10)
} //for (int i = 0; i < 20; i++)Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
Kings Tools[^] does this automatically for you. :) Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Ok, be a bit more fair:
bool fooContainsBar = foo.Hierarchies.Contains(bar); bool barMeetsCriteria = bar.Children.TrueForAll(myPredicate); if (fooContainsBar && !barMeetsCriteria) { DoSomethingCrazy(x, y, z); }vs
bool fooContainsBar = (someHierarchy.Hierarchies.Contains(bar) == true); bool barMeetsCriteria = (bar.Children.TrueForAll(myPredicate) == true); if (fooContainsBar == true && barMeetsCriteria == false) { DoSomethingCrazy(x, y, z); }The whole not-inlining-conditions was part of my change as well.
-
Marc Clifton wrote:
saying "if (x==true)" really is redundant.
With all respect due, it really does provide for clearer if statements. For example, take the more real-life scenario below:
if(foo.Hierarchies.Contains(bar) && !bar.Children.TrueForAll(myPredicate)) DoSomethingCrazy(x,y,z);
Looking at that, I really have to study the code carefully so as not to miss anything. Is it asking whether foo's hierarchies contains bar and the bar's children don't pass the criteria by myPredicate? Is that a true or false? If I miss one exclamation point, the code will be logically flawed. That's my main reason for switching syntax; the possiblity for developer error is greatly decreased using explicit is true/is false flags. Compare this to the more verbose, yet clearer replacement:
bool fooContainsBar = (someHierarchy.Hierarchies.Contains(bar) == true);
bool barMeetsCriteria = (bar.Children.TrueForAll(myPredicate) == true);
if (fooContainsBar == true && barMeetsCriteria == false)
{
DoSomethingCrazy(x, y, z);
}It is obvious to any developer, even one unfamiliar with the code what's going on. You can literally read what's going on, rather than trying to infer it with the previous example. I used to be of the persuasion that the former syntax was better because it was quick & dirty and required very little effort to write. But as I come back to code I wrote several months ago, I find myself trying to infer the purpose of the code from these if statements. When I write the code in a more verbose, yet clearer style, there is no having to infer the purpose of the code or find out what's going on. You simply read, "if foo contains bar, and bar's children do not meet the criteria, do something crazy". I find this far superior. Yes, comments can help infer purpose, but comments are not always present or up-to-date, and are obviously not compiler-checked for logical correctness.
Marc Clifton wrote:
And it can lead to errors, like "if (x=true)"
Actually, if you do this in C#, you'll get a compiler warning saying "Assignment in conditional expression is always constant; did you mean to use == instead of = ?". In the project I've been working on for the last 3-4 years, I've never once made that mistake because the compiler will catch it and alert me should I accidentally type one less equal sign.
Tech, life, family, faith:
Testing against
trueis really dangerous, particularly if you have to deal with COM VARIANT_BOOL or MFC style BOOL types as well as the built in bool type. This also applies if you are testing the return values of SDK functions which return != 0 for success. If you're in the habit of testing (function() == true) your code will fail as soon as the result is anything other than 1 (true) or 0 (false). If you must explicitly test against boolean types (and quite honestly seeing code in that style gives me a headache and the urge to refactor the offending code), you'd be better advised to test againstfalse, which has the same value (0) in all three types, and generally indicates failure when returned from SDK functions. [edit] One other thing that's just occurred to me about testing booleans is that each occurrance will generate a Lint warning such as 731 ("Boolean argument to equal/not equal"). If (like me) you've ever worked in an team in which we had to justify every lint message in a formal code review you quickly learn to code in a style which generates far fewer warnings.... [/edit] Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work. -- modified at 3:35 Saturday 31st December, 2005 -
Actually, I find the second example harder to read. I have to go back to the bool initialization to figure out what the state test is to validate it, and I have to remember that == takes precedence over &&. And I'm especially thrown off by the use of the () in the bool initializer, where for my personal tastes, the parens around ((fooContainsBar==true) && (barMeetsCriteria==false)) is much clearer. [edit]Actually, "if (fooContainsBar && barMeetsCriteria)" is clearest of all, to me. :) [/edit] In the first example, the only improvement I would make would be to implement a FalseForAny method to avoid the !x.TrueForAll.
Judah Himango wrote:
Actually, if you do this in C#, you'll get a compiler warning saying
Yes, I know that, but I still see people ignoring warnings, just as they don't have the discipline to keep comments up to date. But, back to the issue of code clarity, what I'm realizing is that this is probably subjective. But subjective in an operational sense--I didn't have any problems at all with the first code example, and find the second one more difficult. It brings to light that people comprehend code with different efficiencies depending on the coding style, and that's a pretty critical thing when it comes to working in a team environment. Marc Pensieve -- modified at 12:40 Friday 30th December, 2005
I think the key here is that when you're looking at months-old code, you're usually trying to understand what the condition is. The condition is self-explanatory because of the variable names outside the if statement. One can, at a glance, infer what the condition is by looking at the if statement, which cannot be said of the first example, at least not for me.
Marc Clifton wrote:
[edit]Actually, "if (fooContainsBar && barMeetsCriteria)" is clearest of all, to me. :) [/edit]
Actually, that's wrong too. What you meant to say was, "if (fooContainsBar && !barMeetsCriteria)" is clearest to you. Which is ironic, because that is one reason why I prefer == true or == false instead of the presence or absence of exclamation points to symbolize true or false.
-
Kings Tools[^] does this automatically for you. :) Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Cool! Is there one for C#? It looks like this one is just for C++. Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
-
Cool! Is there one for C#? It looks like this one is just for C++. Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan Portland, Oregon, USA
I've not tried it in C#, but given that the add-in is written in VB.NET, I wouldn't be at all surprised if it worked already. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Testing against
trueis really dangerous, particularly if you have to deal with COM VARIANT_BOOL or MFC style BOOL types as well as the built in bool type. This also applies if you are testing the return values of SDK functions which return != 0 for success. If you're in the habit of testing (function() == true) your code will fail as soon as the result is anything other than 1 (true) or 0 (false). If you must explicitly test against boolean types (and quite honestly seeing code in that style gives me a headache and the urge to refactor the offending code), you'd be better advised to test againstfalse, which has the same value (0) in all three types, and generally indicates failure when returned from SDK functions. [edit] One other thing that's just occurred to me about testing booleans is that each occurrance will generate a Lint warning such as 731 ("Boolean argument to equal/not equal"). If (like me) you've ever worked in an team in which we had to justify every lint message in a formal code review you quickly learn to code in a style which generates far fewer warnings.... [/edit] Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work. -- modified at 3:35 Saturday 31st December, 2005Since I'm using almost exclusively C#, our concept of bool equalling something other than true or false doesn't apply. :)
-
Since I'm using almost exclusively C#, our concept of bool equalling something other than true or false doesn't apply. :)
Fair enough, although I still think its a very bad habit to get into, especially if you do any interop work. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Testing against
trueis really dangerous, particularly if you have to deal with COM VARIANT_BOOL or MFC style BOOL types as well as the built in bool type. This also applies if you are testing the return values of SDK functions which return != 0 for success. If you're in the habit of testing (function() == true) your code will fail as soon as the result is anything other than 1 (true) or 0 (false). If you must explicitly test against boolean types (and quite honestly seeing code in that style gives me a headache and the urge to refactor the offending code), you'd be better advised to test againstfalse, which has the same value (0) in all three types, and generally indicates failure when returned from SDK functions. [edit] One other thing that's just occurred to me about testing booleans is that each occurrance will generate a Lint warning such as 731 ("Boolean argument to equal/not equal"). If (like me) you've ever worked in an team in which we had to justify every lint message in a formal code review you quickly learn to code in a style which generates far fewer warnings.... [/edit] Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work. -- modified at 3:35 Saturday 31st December, 2005Anna-Jayne Metcalfe wrote:
Testing against true is really dangerous, particularly if you have to deal with COM VARIANT_BOOL or MFC style BOOL types as well as the built in bool type. This also applies if you are testing the return values of SDK functions which return != 0 for success.
I tend to prefer a little more verbose than a lot less verbose. But overall, I think consistency is the most important thing. This is something a hate about Microsoft - they are not consistent. While it's true that most Win32 APIs return !=0 for "success", most if not all MSI APIs return ERROR_SUCCESS = 0. I think this is incredibly bad practice.
-
Anna-Jayne Metcalfe wrote:
Testing against true is really dangerous, particularly if you have to deal with COM VARIANT_BOOL or MFC style BOOL types as well as the built in bool type. This also applies if you are testing the return values of SDK functions which return != 0 for success.
I tend to prefer a little more verbose than a lot less verbose. But overall, I think consistency is the most important thing. This is something a hate about Microsoft - they are not consistent. While it's true that most Win32 APIs return !=0 for "success", most if not all MSI APIs return ERROR_SUCCESS = 0. I think this is incredibly bad practice.
rwestgraham wrote:
While it's true that most Win32 APIs return !=0 for "success", most if not all MSI APIs return ERROR_SUCCESS = 0. I think this is incredibly bad practice.
Very true. Lack of consistancy is dangerous. The one that really annoys me is
ShellExecute(): Returns a value greater than 32 if successful, or an error value that is less than or equal to 32 otherwise. The following table lists the error values. The return value is cast as an HINSTANCE for backward compatibility with 16-bit Windows applications. It is not a true HINSTANCE, however. The only thing that can be done with the returned HINSTANCE is to cast it to an int and compare it with the value 32 or one of the error codes below. While I can understand their reasoning to an extent (compatibility with 16 bit apps) this quite simply sucks. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.