logoalt Hacker News

bluGillyesterday at 6:26 PM1 replyview on HN

I've seen seniors and juniors bring novel tools in. Seniors do it less often perhaps - but only because we have seen this before under a different name and realize it isn't novel. (sometimes the time has finally come, sometimes it fail again for the same reason it failed last time)


Replies

JKCalhounyesterday at 7:15 PM

I've seen seniors bring up novel ideas to juniors—well, novel to the juniors anyway.

Just an example. I've been in so many code bases over the years… I had a newer engineer come aboard who, when he saw some code I recently wrote with labels (!) he kind of blanched. He thought "goto == BAD". (We're talking "C" here.)

But this was code that dealt with Apple's CoreFoundation. More or less every call to CF can fail (which means returning NULL in the CF API). And (relevant) passing NULL to a CF call, like when trying to append a CF object to a CF array, was a hard crash. CF does no param checking. (Why, that would slow it down—you, dear reader, are to do all the sanity checking.)

So you might have code similar to:

CFDictionary dict = NULL;

dict = CFCreateDictionary();

if (!dict)

    goto bail;
You would likely continue to create arrays, etc—insert them into your dictionary, maybe return the dictionary at the end. And again, you checked for NULL at every call to CF, goto bail if needed.

Down past 'bail' you could CFRelease() all the non-null instances that you do not return. This was how we collected our own garbage. :-)

In any event, goto labels made the code cleaner: your NULL-checking if-statements did not have to nest crazy deep.

The new engineer admitted surprise that there might be a place for labels. (Or, you know, CF could have been more NULL-tolerant and simply exited gracefully.)