Expressive or verbose syntax?
-
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 / MyHTMLTidyIn 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
-
Well, I hope programming polls are not banned from the Lounge yet ;) Do you prefer expressive or verbose syntax? Personally, I prefer verbose, but ironically, I have almost exclusively programmed with languages that have expressive syntax - sometimes because I liked the semantics of the language (C, C++), and sometimes simply because the employer/customer demanded it (C#, Java, Perl). Anyway, I find odd that in 21st century with all the powerful editors and big screens most popular programming languages (except Visual Basic, I guess) are expressive. Isn't readibility more important than typing speed?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
If you can't express your thoughts clearly with well formed, grammatically correct sentences, the words you use are irrelevent. Same goes for programming. ;P Marc Pensieve
-
Expressive, but to a point. Developers get carried away with making code look small and succinct, and you end up with things like
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;evalAnd yes, that is real Perl code. :) In the face of that, I think I'd rather be using Visual Basic with its extra-verbose syntax. I think there is a line between code that's too fat & chatty and slopped-together-lines-to-make-it-look-small code. In light of that, I've recently changed my style from
if(someBoolVal) DoSomethingWithBlah(x, y, z);
to
if (someBoolVal == true)
{
DoSomethingWithBlah(x, y, z);
}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.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Bought a House! Judah Himango
-- modified at 10:54 Friday 30th December, 2005
Judah Himango wrote:
Yes, it is more verbose,
Except in C#, the only time you can have "if (x)" is when x is a boolean! So, saying "if (x==true)" really is redundant. And it can lead to errors, like "if (x=true)", which is why, when people compare a constant to a var, they tend to prefer the format "if (true==x)", though I personally have a distate for that because it doesn't read well. Complicated, isn't it? Perhaps:
// When someBoolVal is true, we need to do the blah so that foobar happens.
if (someBoolVal)
{
DoSomethingWithBlah(x, y, z);
}would actually be better. Too often, we think that something can be improved within the same context, while in reality, we need a different context (like a comment, rather than code) to make things clearer. Marc Pensieve
-
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 / MyHTMLTidydnh wrote:
That's what IDE (syntax highlight, #region) is for!
And if you are reading the code from a book, or a web site?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Expressive, but to a point. Developers get carried away with making code look small and succinct, and you end up with things like
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;evalAnd yes, that is real Perl code. :) In the face of that, I think I'd rather be using Visual Basic with its extra-verbose syntax. I think there is a line between code that's too fat & chatty and slopped-together-lines-to-make-it-look-small code. In light of that, I've recently changed my style from
if(someBoolVal) DoSomethingWithBlah(x, y, z);
to
if (someBoolVal == true)
{
DoSomethingWithBlah(x, y, z);
}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.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Bought a House! Judah Himango
-- modified at 10:54 Friday 30th December, 2005
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
-
If you can't express your thoughts clearly with well formed, grammatically correct sentences, the words you use are irrelevent. Same goes for programming. ;P Marc Pensieve
Marc Clifton wrote:
If you can't express your thoughts clearly with well formed, grammatically correct sentences, the words you use are irrelevent.
I beg to disagree. Compare[^]:
foreach my $line ( <> )
{
my @record = map {s/"//g; $_} split("\t", $line);
push(@records, \@record);
}with
for line in fileinput.input():
record = [field.replace('"', '') for field in line.split("\t")]
records.append(record)I have programmed with Perl *much* more than with Python, but still find the Python code easier to read.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Well, I hope programming polls are not banned from the Lounge yet ;) Do you prefer expressive or verbose syntax? Personally, I prefer verbose, but ironically, I have almost exclusively programmed with languages that have expressive syntax - sometimes because I liked the semantics of the language (C, C++), and sometimes simply because the employer/customer demanded it (C#, Java, Perl). Anyway, I find odd that in 21st century with all the powerful editors and big screens most popular programming languages (except Visual Basic, I guess) are expressive. Isn't readibility more important than typing speed?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
Oh dear! I fear it's religious war time again or "C-family zealots bash all languages that don't use curly brackets." I'm primarily a C-family guy myself. However, I do feel that the ideal for readability should be somewhere between C#/Java and VB. A language such as Eiffel gets the balance about right. Also, Python and Ruby strike good balances between conciseness and readability. VB is verbose in the sense of being too wordy - but I can live with it if necessary. C# could be a bit more readable but again I can live with it. Kevin
-
Marc Clifton wrote:
If you can't express your thoughts clearly with well formed, grammatically correct sentences, the words you use are irrelevent.
I beg to disagree. Compare[^]:
foreach my $line ( <> )
{
my @record = map {s/"//g; $_} split("\t", $line);
push(@records, \@record);
}with
for line in fileinput.input():
record = [field.replace('"', '') for field in line.split("\t")]
records.append(record)I have programmed with Perl *much* more than with Python, but still find the Python code easier to read.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
Nemanja Trifunovic wrote:
but still find the Python code easier to read.
But perhaps that's because it's more native to the language you use in life. I remember when I first came across C and was appalled at the syntax, like +=, ==, *foo.bar vs. foo->bar, and so forth. But eventually it became second nature, a second language, if you will. Though, it took a long time for me to use the language in (and here's that word again) it's "vernacular". And it's that transition that makes the difference between code being readable to someone with a basic understanding of the language vs. someone who codes the language like a "native". While understanding the syntax is necessary to understand the meaning of a piece of code, I'm not sure, in your example, that understanding is really improved using Python. I would still prefer a comment that describes what that segment of code does! Marc Pensieve
-
Nishant Sivakumar wrote:
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?
Sure, but I would rather read somethnig like:
end forend function
end classthan
}}
}
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
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
-
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
I agree.:) Kevin
-
Marc Clifton wrote:
If you can't express your thoughts clearly with well formed, grammatically correct sentences, the words you use are irrelevent.
I beg to disagree. Compare[^]:
foreach my $line ( <> )
{
my @record = map {s/"//g; $_} split("\t", $line);
push(@records, \@record);
}with
for line in fileinput.input():
record = [field.replace('"', '') for field in line.split("\t")]
records.append(record)I have programmed with Perl *much* more than with Python, but still find the Python code easier to read.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
Nemanja Trifunovic wrote:
I have programmed with Perl *much* more than with Python, but still find the Python code easier to read.
Yes, Python is far superior in readability than Perl. Perl is the worst of the lot. Kevin
-
Nemanja Trifunovic wrote:
but still find the Python code easier to read.
But perhaps that's because it's more native to the language you use in life. I remember when I first came across C and was appalled at the syntax, like +=, ==, *foo.bar vs. foo->bar, and so forth. But eventually it became second nature, a second language, if you will. Though, it took a long time for me to use the language in (and here's that word again) it's "vernacular". And it's that transition that makes the difference between code being readable to someone with a basic understanding of the language vs. someone who codes the language like a "native". While understanding the syntax is necessary to understand the meaning of a piece of code, I'm not sure, in your example, that understanding is really improved using Python. I would still prefer a comment that describes what that segment of code does! Marc Pensieve
There is some truth in this. But I still find C a model of clarity compared to Perl. The latter is truly dreadful - the worst language I've used so far. Kevin
-
dnh wrote:
That's what IDE (syntax highlight, #region) is for!
And if you are reading the code from a book, or a web site?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
You can use comments... yes you are right that "end function" reads better then "}", IMHO it would be cool if one could use both, for one-liners curlies are priceless. Think
myClass.MyFunction(){ return i; };
vs.
function myClass.MyFunction()
return i;
end function;or even
function myClass.MyFunction() return i; end function;
X| Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidy -
Judah Himango wrote:
Yes, it is more verbose,
Except in C#, the only time you can have "if (x)" is when x is a boolean! So, saying "if (x==true)" really is redundant. And it can lead to errors, like "if (x=true)", which is why, when people compare a constant to a var, they tend to prefer the format "if (true==x)", though I personally have a distate for that because it doesn't read well. Complicated, isn't it? Perhaps:
// When someBoolVal is true, we need to do the blah so that foobar happens.
if (someBoolVal)
{
DoSomethingWithBlah(x, y, z);
}would actually be better. Too often, we think that something can be improved within the same context, while in reality, we need a different context (like a comment, rather than code) to make things clearer. Marc Pensieve
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:
-
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