Tag Archives: String

JavaScript test for integer / string

Posted on by
2 Replies

I couldn’t find either of these functions that satisfied my edge cases or desire for simplicity so I wrote/adapted some of my own. Feel free to use, modify, distribute without attribution, but I’d be eternally grateful if you did ;)

The test for integer is adapted from this post, which is actually almost spot on, apart from their is_int([0]) returns true, as does any integer in a string.

I’m pretty sure I’ve seen this test for string a hundred times on the internet and in books. It is by far the most robust:

Please let me know if you can break it!

Stringly Typed Booleans

Posted on by
11 Replies

I’m getting rather hacked off seeing boolean properties typed as strings. Stringly typed is a phrase I learnt off a post from the excellent Coding Horror blog and it describes a phenomena whereby properties that are of a specific type, e.g. Boolean, Date, int, are stored needlessly as strings.

I’m working on a website that communicates with a money laundering service to check whether an individual is “bad” or not. Individuals can pass the test, but importantly it is possible to pass the test with some warning flags raised. If any of the warning flags are raised then an email should be sent off to compliance for them to do…whatever it is they do. Fair enough right?

The warning flags are obviously booleans. There was either a warning raised or there wasn’t – there are no two ways about it (no pun intended). In the serialized response, the warning flags are encoded as “Yes” or “No”…which is understandable. Now, upon receiving the response, it is parsed and turned into an internal representation. This is where things get really weird. The programmer that coded the object that stores the response from the service has decided to encode the warnings as strings, initialised to “”. Which is totally fucking bonkers.

Why?

Well, now our boolean warnings aren’t really booleans – they have WAY more than two possible values and the meaning of these values is subjective. One may consider “”, null, “No” as false, but could conceivably also consider “false” or “0″. We get the same sort of problem with true – “Yes”, “1″, “true” and then we get a whole load of unknown values which is every other possible string in the world. Which might be considered to be true.

So how the hell can any number of programmers work on this piece of code without introducing errors because of differing definitions of truthy and falsey values? Well, they can’t. To illustrate the problem further, even loosely typed languages differ in their boolean coercion, for example JavaScript and PHP:

<script>
if("0") alert('Opposite day!');
</script>

<?php
if("0") echo 'Opposite day!';
?>

JavaScript considers “0″ true but PHP considers it false. Personally I think JavaScript is “right” here, but as I said before, it is totally subjective.

The icing on the cake is of course the extra code you have to write to check the truthy or falsey string values. Something along the lines of “if x is not null and not empty and not the word No then it is probably true…probably”, which would otherwise have been coded as “if x then true” if x was a boolean – which is orders of magnitude shorter.

Of course, there are some bat shit crazy strongly typed languages that allow you to assign null to a Boolean, but that is a different story altogether.

The difference between using single quotes and double quotes as string delimiters in JavaScript/PHP

Posted on by
8 Replies

I like to keep all my string delimiters in languages such as PHP and JavaScript consistent. I consistently use single quotes for a couple of good reasons, so when I encounter someone else’s script that uses double quotes the OCD in me makes me change them all to single quotes…but that is a different problem.

If you’re coming from a language such as C# or Java then note that in PHP and JavaScript there is no such thing as a character datatype – as such, you can use either single or double quotes to delimit strings.

If I could only give you one reason why I consistently use single quotes then I would have to go with this:

If you ever (God forbid) need to write HTML in a string, you don’t need to escape the double quotes around attribute values. Instead of:

    "<div id=\"foo\" class=\"bar\">foobar</div>"

You write:

    '<div id="foo" class="bar">foobar</div>'

…which is lots less characters to type and I’d say more readable. Also, I more frequently use double quotes in my JavaScript/PHP strings than single quotes so it really does make sense.

The other reason is that if you use double quotes, PHP will actually parse the contents of the string to find variables and escape characters (\n, \r, \t etc.) which it’ll replace with the variable value or correct escape character respectively. So for example:

<?php

    $baz = 'bar';
    echo "foo\n$baz";

?>

Will print:

foo
bar

Whereas:

<?php

    $baz = 'bar';
    echo 'foo\n$baz';

?>

Will print:

foo\n$baz

So if you don’t need any of this functionality in your string, you’re making PHP do some extra work for no reason.