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 RayWenderlich.com 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. 🙂