The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Stupid Syntax Preference

I'm just curious.. which do you prefer? Which is more readable?

---

OPTION 1:

char test_string = "xyz"
boolean test

if (test_string == "")
{
  test = true
}
else
{
  test = false
}


OPTION 2:

test = (test_string == "")

----

I know that the bracket-style in "option 1" could be rewritten a dozen different ways, but that's secondary for the purpose of this example.

I'm just curious what you'd rather have to maintian?
Shane Harter Send private email
Friday, March 17, 2006
 
 
Option 1 triggers an alarm switch "Programmer who may not understand booleans and boolean evaluations."
Secure
Friday, March 17, 2006
 
 
Option 2 all the way. Some people would say that Option 1 is more readable but I think they're discounting programmers with any sort of experience from that statement.
John Topley Send private email
Friday, March 17, 2006
 
 
Option 2. Definitely.

The only reason to split up code like that is for easy placement of breakpoints.
Jeb
Friday, March 17, 2006
 
 
Option two for me too. The first option just has more room for error, there fits less information on your screen with these verbose constructs and it just does not look right.  Just like:
switch(i){
  case 1: return 1*x;
  case 2: return 2*x;
  ...
  case N: return N*x;
}
would not feel right :)
Michiel van Vlaardingen Send private email
Friday, March 17, 2006
 
 
Opt 2 for me.  With every line of code you don't type, there is that much less chance there is a bug in it. Also, who can't read #2?  Do we really need to pander to those people. 

[Note:  I am ignoring the possibility that something like this might happen if the programmer where trying to use breakpoints.  s/he should refactor the code afterwards.]
Joshua Volz Send private email
Friday, March 17, 2006
 
 
In a language which has good support for string comparisons, I prefer option 2 but I'd not be fond of:

  test = strcmp(test_string, "") != 0;
Chris Nelson Send private email
Friday, March 17, 2006
 
 
How would you all feel about this ever-so-slightly-modified version?

test = (test_string != "");

The nice and normal positive logic ones are easy to understand, but what about the ones that delve a little bit into negative logic by necessity?
Ryan Phelps Send private email
Friday, March 17, 2006
 
 
In my old C days, I would have used:

test = (*test_string == '\0');

strcmp(test_string, "") seems like a waste of CPU cycles.
MBJ Send private email
Friday, March 17, 2006
 
 
>>How would you all feel about this ever-so-slightly-modified
>>version?

>>test = (test_string != "");

Actually.. this isn't too hard. I read this as:

Test = true if not empty.

Not too complicated.

But I can see how someone could get a little tripped up by it.
Shane Harter Send private email
Friday, March 17, 2006
 
 
Option 3. Is it really necessary to cache the comparison results?
son of parnas
Friday, March 17, 2006
 
 
test = (test_string != "");

Why not just write
test = (test_string == "");

Only very seldom a negative makes sense in a situation like this.

sGuestUser = (slcUserName == "guest");

or

sNotGuestUser = (slcUserName != "guest");

if (not sNotGuestUser) { ... }

Why would you put a negative in a boolean value? I don't think it makes for better code.
Jeb
Friday, March 17, 2006
 
 
And, fwiw, I much prefer "Option 2."

I'm currently working on a (gasp!) classic-asp website for a client that has requested that maintainability and readability be the single most important attributes.

Of course, these things are always important, but usually they are balanced along with code-efficency, modularization for reuse, the fact that certain things are just complex, etc, etc...

And you can imagine how much verbage Option2 saves in VBScript:

if (test_var = "") then
 test = true
else
 test = false
end if

ugh...

I learned VBscript first about 5 years ago. I started with VB6 about a year after that.

I never understood the arguments against the VB-style syntax. To me, it was easy: you just read it! Compare that to the "c-style" syntax where you can't see the actual code because you're too busy looking at curleys and apos.

Then I took a PHP job for a year. Now I am enlightened =D
After this website, on to my first C# project....
Shane Harter Send private email
Friday, March 17, 2006
 
 
son of parnas,

In the code I was writing that prompted me to post this, test_string was inside of a function that returned boolean.

So in this case, yes, it is necessary =D
Shane Harter Send private email
Friday, March 17, 2006
 
 
I think SoP refers to the "local variables are evil" pardigm that seems to be big with the agile folks nowadays.

Maybe you could've written

return (str1 != str2);

and eliminated the boolean variable in the process.
Jeb
Friday, March 17, 2006
 
 
> test_string was inside of a function that returned boolean.

Then this would work:

return string == "xxx"


>  I think SoP refers to the "local variables are evil"

I don't think they are evil. If will use them if I need to cache the result for later use rather than evaluate an expression multiple times. But hey, if you don't need to I would complicate things by caching.
son of parnas
Friday, March 17, 2006
 
 
>> Then this would work:

>> return string == "xxx"

... I mentioned in a post that I was actually writing vbscript when I posted... In vbScript you actually return values from functions like my code shows.

thanks for the gusto, tho....
Shane Harter Send private email
Friday, March 17, 2006
 
 
Regarding that test string above, my favorite is

test = !test_string;
Berislav Lopac Send private email
Friday, March 17, 2006
 
 
> test = (test_string != "");
Would be better as:
testStringNonempty = (test_string != "");
Joe
Friday, March 17, 2006
 
 
Wow.  I've never used option #2.  Can't wait to try it.
anon
Saturday, March 18, 2006
 
 
Option 1.

- Clarity
- Less chance of =/== bugs
- Allow to inspect and manipulate the logic during debug

Option 2 is for those who live on the edge, are willing to take risk, wanna cram too many logics in one statement and wannabe "cool" people.

But I am boring and "uncool".
RM
Saturday, March 18, 2006
 
 
option 2
or more preferred:
test = ("" == test_string);
to prevent accidental assignment

cheers
Simon
Saturday, March 18, 2006
 
 
RM - I lean toward the "uncool" and boring clarity myself, but in this case I'd go for Option 2. I actually find it more clear.

Berislav's alternative (test = !test_string) might fall into my "too cool" category - but it *is* cool!
EKB Send private email
Sunday, March 19, 2006
 
 
Option 2 has almost every argument going for it: shorter, simpler, clearer,...  So why  would anyone use option 1?

There might be some sensible reason, such as making for easier use of a debugger.  But even that doesn't make sense for such a simple statement.  Or maybe it just evolved from a more complex piece of code that never got cleaned up.

But the thread reminds me of a discussion I had many years ago concerning a piece of FORTRAN code.  A program had been delivered to a customer and contained a statement sort of like:
    LOGICAL  LS, LA, LB
    ...
    LS = LA .AND. LB

I had quite a time on the phone convincing one of the customer's programmers that this was perfectly valid FORTRAN.

So I suspect the replies from Secure and John Topley are most appropriate.  Just like there are some people who just don't get pointers, there are some who can't generalize the concept of expression evaluation and assignment to a variable to include boolean or comparison operations.
argon Send private email
Sunday, March 19, 2006
 
 
I'm not too sure what's "too cool" about Option 2. I certainly don't get upset at seeing Opt1, because it could have evolved out of something else or was originally intended for expansion into something a bit more complex. But the implication that Opt2 is unclear or misguided surprises me.

I started as a hobbyist (mumble) years ago with a VIC-20 and the *excellent* Programmers Reference Guide that came with it. If I didn't learn the technique from the book, then that means I came up with it on my own and I'm really not all that bright as far as programmers go. Either way, it's been a standard construction in my code for lo these many years. Of course, there are certain English constructions that I'd be better off without and the same may be true here.

I fail to see how one can classify this as being anything complicated, obscure, egotistical, or misguided. I would have thought that

x = y == z;

and similar constructions would be considered the programmer's equivalent of "See Jane run." (look up "Dick and Jane" early reader if you don't get the reference.)

I write my code for clarity with two audiences in mind: the programmer who takes over from me and the compiler itself. I guess someone is in for a helluva ride if I've misjudged the capabilities of my audience :)
Ron Porter Send private email
Monday, March 20, 2006
 
 
I'd prefer option 3 - don't declare the variable test until you're ready to give it a value. And if it doesn't change subsequently, make it const:

const bool test = (test_string == "");
Stephen C. Steel Send private email
Monday, March 20, 2006
 
 
The benefit of option 1 is that it is extremely easy to expand in the future, with minimal risk of added bugs.

What's being left out of this discussion is WHY you want to check if test_string is empty.  If it IS empty, is there additional stuff you want to do? (which option 1 has already blocked out where that stuff should go).

If it ISN'T empty, is there additional stuff you should do?  Again, option 1 has this blocked out too.

So basically, you've taken a 'toy' example, and reduced it to almost nothing -- test = (test_val == "");

But in the real world, you would then do something with 'test', no?  So you're going to have that
if (test)
{
  // do something
}
else
{
  // do something else
}
 in your code somewhere else, no?  Might as well replace that 'test' with 'test_val == ""' in the 'if' in the first place.

The first option is better software engineering for the future.
AllanL5
Tuesday, March 21, 2006
 
 
"The first option is better software engineering for the future."

This depends, especially when the tests become more complicated. The second option is usually recommended for maintainability, e.g. in Code Complete: "Use boolean variables to simplify complicated tests."

The better solution might be to use option 2, together with a speaking variable name, esp., as you said, when the result will be used later (else the assignment would be senseless).

is_empty = (test_string == "")
Secure
Tuesday, March 21, 2006
 
 
return (test_string == '') ? true : false

for the semantically challenged VB, then.

Must agree with SoP: if you ain't gonna use a value more than once (within a scope) why you caching it?
Spinoza Send private email
Tuesday, March 21, 2006
 
 
I've actually said this once already. This is a vbscript project. To return from a function in vbscript you assign the value to the function itself.

Example:

function test(x)

 test = (x = "")

end function

... i think this should be clear now.
Shane Harter Send private email
Tuesday, March 21, 2006
 
 
test = (condition) ? true : false
Spinoza Send private email
Thursday, March 23, 2006
 
 
I have a lot of Java (pre 1.5) code that looks like:

boolean someFlag = ...
... //do some work with the primitive
//then later...
Boolean someFlagBoolean = someFlag ? Boolean.TRUE : Boolean.FALSE;
someCollection.add(someFlagBoolean);
Java GUI Programmer
Friday, March 24, 2006
 
 
+1 for
test = ("" == test_string);
to prevent accidental assignment.

unless you need breakpoint access.
rkj Send private email
Wednesday, March 29, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz