current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote -2 down vote favorite

When converting a string to a boolean, what are the advantages of having a programming language evaluate an empty string as true and what are the advantages of having it evaluate it to false?

share|improve this question

closed as primarily opinion-based by MichaelT, gnat, mattnz, GlenH7, Kilian Foth Oct 10 '13 at 14:03

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
6  
Could you specify the language where you're doing this? It certainly isn't universal. –  MichaelT Oct 7 '13 at 17:53
2  
Common Lisp treats empty strings as true ( rosettacode.org/wiki/Empty_string#Common_Lisp ) –  MichaelT Oct 7 '13 at 18:03
2  
The point I was trying to make with that is that the design decisions for each language as to why empty string is a given truth value are different. One cannot just say ask the broad question. Perl has different design decisions than javascript or ruby. –  MichaelT Oct 7 '13 at 18:12
2  
@JoachimSauer it might be, but I still don't know what the actual problem of the question is. I can't answer the general case because its not universal at all. I could answer explain it for ruby (quite simple - only false and nil are falsy - everything else is truthy). But that doesn't answer the question and many other answers are possible for other languages. –  MichaelT Oct 7 '13 at 18:20
2  
-1: Any question such as this can be adequately answered by exploring the "why not" response. –  mattnz Oct 7 '13 at 19:16

4 Answers 4

up vote 2 down vote

Advantages: You save two seconds of coding time having to type less.

Disadvantages: Code is less intention-evident, making you waste the two seconds you saved having to carefully read and mind-evaluate the line of code everytime you come across it.

share|improve this answer
    
+1 for nice use of bold. –  Andyz Smith Oct 7 '13 at 19:25
    
It takes you two whole seconds to write != null? –  Servy Oct 7 '13 at 19:27
1  
i'd go even further. saves you two seconds it would have taken to consider what you you want to do in the exceptional case when someone passes you a null, and defers it, with interest, until you are deploying ( or porting ) and still haven't thought about null(s) but now it costs 2^10 seconds. –  Andyz Smith Oct 7 '13 at 19:33
1  
@dallin you're just hiding stuff. sometimes it's good to hide, like in a loose script prototype. My objections generally rise from the inevitable and poorly thought out transition of working prototype code into faux, production code. Code that breaks as soon as you move outside your deevlopment crib and get a null string from some kind of Web service with different semantics for marhsalling it's parameters to you. and your code is hard to debug, beause it works. but it's inserting crap into the databas, because your string test evaluates to false automatically;unintentionally –  Andyz Smith Oct 7 '13 at 23:21
1  
@dallin true dat. for me, empty evaluating to boolean always leaves a bug in the last place you'd expect; routines that have been tested repeatedly and are working. you waste a lot of time testing new or changed code, the typical sage advice. so in a big, integrated, multi variable debugging problem, it's a bit of a nightmare to find out that you're simply falling through to false somewhere that is supposed to be bulletproof already –  Andyz Smith Oct 8 '13 at 0:24
up vote 3 down vote

Converting a string to boolean true or false and other implicit conversions are charterized thusly...

The advantages: possibly more succinct,clever looking code; possibly some more fluidity and expressiveness when writing code quickly; maybe good for quick and loose prototypeing or scripting

are easily outweighted by the

Disadvantages: confusing, lacking portability, reduces maintainability, and verges on intentional obfuscation

Because

Hiding complexity behind built-in 'tricks' of each language is clever at first and devastating later. if the subject is complex, like str can be undefined type, str can be null, str can be defined, not null, but blank, YOU the programmer must be explicit how you want deal with this. at the point of usage. not buried in some docs on the JavaScript API

Also note that many of these pros and cons also apply to excessive use of operator overloading, which this is a special case of, basically.

share|improve this answer
up vote 5 down vote

In the context of JavaScript (I'm guessing this is what generated the question), an empty string evalutes to false in a boolean context because it allows you to use the pattern if (str). If an empty string didn't evaluate to false (along with other states like null or undefined), you would have to do the following: if (typeof str !== "undefined" && str != null && str !== "").

This is far more verbose.

An alternate interpretation is that the default state of a primitive evaluates to false. For booleans, this is false. For integers, this is 0. For strings, that would be an empty string. Conceptually, there's no guarantee of nulls existing in a given type system, a value should have a default state.

share|improve this answer
1  
There is no guarantee of "default states" existing in a given type system either... –  Andres F. Oct 7 '13 at 19:45
up vote 0 down vote

Consider this pseudo-code:

print "First name: " + firstname
if middlename:
  print "Middle name: " + middlename
print "Last name: " + lastname

This and many related cases is where "empty string is false-ish" is useful. Keep in mind that direct evaluation of non-boolean values as boolean is usually restricted to script-ish languages that where build with user interfaces in mind.

share|improve this answer
    
Did you mean to say "false-ish"? To rephrase your answer, are you saying, "Because you can write less"? –  Daniel Kaplan Oct 7 '13 at 18:08
    
@tieTYT: yes, of course (fixed it). Yes: less typing is pretty much what the whole "allow non-boolean expressions in places where boolean makes sense" is all about. Because you could always just make the "real" condition explicit. –  Joachim Sauer Oct 7 '13 at 18:09
    
@JoachimSauer Well, the origin of that practice is from languages like C (or perhaps an older language, that I don't know) where there was no boolean type, you always used an integer or some other numeric type to represent a boolean instead as a hack. Since a pointer is also a numeric type, with the zero value being the null pointer, this (unfortunately) resulted in the practice of relying on if(pointer) being a null check. Because the convention became so widely used it seems other languages allowed the syntax, while others choose to prevent it when adding a Boolean type. –  Servy Oct 7 '13 at 19:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.