And style keeps evolving

My coding style (programming) has evolved over time.

The biggest change I made wasn’t too long ago, when the NYTimes Style Guide came out. There were some style things in there that I had long resisted, but they made a solid case for that wasn’t just good style but also had functional implication.

One of the biggest was dealing with BOOL types.

See, while BOOL uses YES and NO as the logical constants, there’s nothing that says it must work out that way because BOOL isn’t as deeply ingrained in the Objective-C language as say bool is in the C++ language. You can read the NYTimes guide for the reasoning and style, and it’s a solid reason. I actually found myself getting bit by this very thing in an interesting way.

This is from memory, but it was something like:

- (BOOL)checkForSomeCondition {
  return (BOOL)foo; // where 'foo' was SomeObject*

Most of the time, things worked. But sometimes I had strange behaviors and crashes, which ultimately tracked down to this. I saw in the debugger that the foo pointer was non-nil, but yet it returned NO. I think that’s how it was going. Basically the logic wasn’t working out given the value of foo. So I changed it:

- (BOOL)checkForSomeCondition {
  return foo ? YES : NO;

and things worked. Hooray for compilers and scalar sizes, right?

But you can see how subtle things can bite you. And furthermore, it also shows that if I checked the return value of -checkForSomeCondition by seeing if it was equal to YES or NO, I may not have gotten the right behavior.

So that was a solid coding style change.

Now, the fantastic folks over at just created their own style guide. But their intention was a little different, because they were more concerned about style for their tutorials — print and web. Nevertheless, there are a few great things in their style guide that even in my 20 years of doing this, I hadn’t directly thought about.

1. I need to remember to use the CGRect functions instead of accessing the struct values directly. This is just bad habit that I need to work on breaking.

2. The “Golden Path”. I’ve never explicitly thought about this, but once you see it you’re like “duh!”. I always had mixed emotions about this, because it just depended. I never liked “littering” the top of methods with a lot of “if it’s not this, return” type of things. I tended to like a positive conditional flow. But yes, that could lead to a lot of nesting, which would be really bothersome if that led to a deep nest before you got to the meat of things, or if the method implementation was long (e.g. more than a screen, which can happen despite best efforts). This is something I’ll consider more as I code.

I like a lot of the things in Ray’s style guide, but there are things I do not like. Mostly those things I don’t like are because it creates exceptions. That is, you should do this, except in this case or that case. That creates too many rules to have to remember, and then things become easy to violate. I prefer to have a single rule, in the spirit of keeping things simple and consistent… because isn’t that a key reason for style? I do accept that exceptions can and must occur on occasion, but they should be the (ahem) exception and not the rule. Reading Ray’s guide felt like there were just too many exceptions. But again, they are writing a guide for a particular paradigm.

Overall I don’t think Ray’s stuff is bad tho. It adopts many established and common conventions and introduces some new ones.

If you have no particular style, just pick some established style and go with it. In time, you’ll see what works, what doesn’t work, and you too will evolve. You’ll find other style guides out there, and there will be gems within it, and new things to consider. That whole “take what is useful and discard the rest” Bruce Lee philosophy. 🙂

4 thoughts on “And style keeps evolving

  1. As for the golden path, I think this is really a situational thing.

    I always try to do whatever makes the code more readable.

    In my experience there isn’t a single perfect answer here as sometimes nested if statements are more readable.

    The opposite is also true though, I have seen some crazy logic put in place because the previous developer thought it was some kind of taboo to have more then 1 return statement.

    • Since I am not an objective-c programmer my curiosity over that bool statement boiled over and I had to look into it.

      Essentially BOOL is defined as a signed char and YES is defined as (BOOL)1 and NO as (BOOL)0.

      This means that you would probably never want to cast an object to BOOL. The results would be undefined regardless of what you did with it after.

      What is interesting is that the result of an expression will return a correctly.

      return foo ? YES : NO;
      is equivalent to
      return (foo != nil);

      That being said, the former is more readable. However, if you weren’t comparing an object to nil it might be more interesting.

      For example:
      return (x == y) ? YES : NO;
      is equivalent to
      return (x == y);

      I am not sure that there is any point to this other than be careful when casting to BOOL. I just found it interesting.

      • Well, it returns correctly so long as you treat “yes/true” as non-zero and “no/false” as zero. If you just care about the condition of the value, not the explicit value itself. Thus why should do things like “if (foo)” or “if (!foo)” instead of “if (foo == YES)” or “if (foo == NO)” because the strict equality may not be the case, but the simple “is it zero or non-zero” check works out.

        I just didn’t always like things like “if (somePointer)” because strictly speaking there is nothing that requires NULL to be 0 (depending upon the language, of course). Granted it’s a pretty stout convention, but IIRC from many many years ago when I worked at Metrowerks and language standards were a bit fresher in my head, I do seem to recall that NULL doesn’t HAVE to be 0… at least in C and perhaps C++ (again, it’s been years since I looked at that part of the standard). But of course, this is Objective-C, which is, strictly speaking, different. And yes, nil is 0, NULL is 0, Nil is 0 (essentially). So it works out for this language and runtime.

        But it really depends what you want. I mean, I think it’s sometimes better to have more verbose code that is explict and potentially bullet-proof. I mean, the former examples you have using ?: is more explicit and going to be larger code… but that’s also potential premature optimization, when it may actually be creating more readable, more maintainable code. I’d rather have code that’s more maintainable.

    • I’ll agree. For me, it was one of those things that stared me in the face for many many years, but for some reason reading it in that article hit me. But I do know it isn’t always right nor best. I think for me the big thing is I wanted to avoid code where I’d have a bunch of things like “if not condition return” cluttering up the start of the function/method. But certainly sometimes that’s clearer and makes the flow better. So, it just removed my reluctance to do that (as a blanket rule).

Join the discussion!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.