News for hackers. Stuff that matters.

A comment on nil, Nil, NULL, NSNull. Parent comment

Re:nil, Nil, NULL, NSNull by alayne on Monday January 07, 2013 @01:18PM (#5022314)
He's not being sarcastic. Maybe a better example of what he is trying to get at is

if (![missleLauncher isDisabled]) { /* declare thermonuclear war */ }

When missleLauncher is nil, thermonuclear war is still declared which may not be the programmer's intent.

[ Parent | on HN ]
Re:nil, Nil, NULL, NSNull by xsmasher on Monday January 07, 2013 @01:28PM (#5022357)
Properties and methods are given "positive" names as a matter of convention, and to make reasoning about Nil easier.

In Objective-C, the question "should I name my method isEnabled or isDisabled?" has a reasonable answer - you consider what makes most sense (or any sense) when called on Nil.

This is probably a good rule for other languages too - "negative" booleans can lead to double-negatives and unreadable code.

[ Parent | on HN ]
Re:nil, Nil, NULL, NSNull by alayne on Monday January 07, 2013 @02:15PM (#5022602)
Even with a positive naming convention, you will have conditionals for the negative case, e.g. if (![str isEqualToString:@"myvalue"]) and falling into its block is not desirable when str is nil. Personally I have had plenty of bugs around things being unexpectedly nil, but I can't think of a case like this where I executed a block unexpectedly.
[ Parent | on HN ]