Expressive or verbose syntax?

Nemanja Trifunovic

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.

Nish Nishant

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

Judah Gabriel Himango

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;eval

And 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

Nemanja Trifunovic

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 for

end function
end class

than

}
}

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

DavidNohejl

That's what IDE (syntax highlight, #region) is for! :rolleyes: Besides, you can always write

} // end for

} // end function
} // end class

But you dont need/have to, and that's my point. Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidy

Judah Gabriel Himango

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

Marc Clifton

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

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

Nemanja Trifunovic

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.

Sean Michael Murphy

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 if construct, 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

Nemanja Trifunovic

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.

Kevin McFarlane

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

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

Jamie Nordmeyer

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

Kevin McFarlane

I agree.:) Kevin

Kevin McFarlane

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

Kevin McFarlane

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

DavidNohejl

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 Gabriel Himango

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 Gabriel Himango

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