What are those bad habits you've developed since you've started coding in Cocoa?
I think making a list of bad habits and actively adding to it and, more importantly, breaking those habits is a good technique to produce your code quality. So start now, get your bad habits off your chest. Maybe other people share your bad habits.
Passing nil to arguments that call for NSError**, pure lazy.
Not unit testing enough. It's really difficult to clean up and refactor code if you don't have unit tests. And without constant refactoring and cleaning, code rot begins to set in and spread.
Using the singleton pattern to share objects, like +[MyObject defaultObject]. This is essentially a global variable that makes for some nice hidden dependencies and coupling. This, in turn, makes code harder to test.
(And other non-exceptional circumstances.)
Since use of exceptions is brought up in another answer here and the documentation referred to in the comments does not stress this point particularly, it is worth emphasising that exceptions should not be used for normal control flow (as is common in some other environments). Exceptions in Cocoa are comparatively extremely expensive. If you want to communicate an error, use an NSError object and the error-handling architecture provided by Cocoa. Don't throw exceptions.
Here's some of mine:
Throwing exceptions without any attempt to catch 'em. I've started to rely on NSError more and more to prevent NSExceptions from flying about like bullets in a John Woo movie, but I still have a lot of exceptional code out there.
Writing a quick class to do X, Y & Z and then forgetting to clean up in dealloc. Leaks ahoy!
Using strings directly in various places (KVO) instead of defining a constant and using that (see Dave Dribin's excellent blog post on KVO for more)
I get lazy about using accessors inside of classes. Usually, the biggest problem is that I can't easily tell the scope of the variable at a quick glance. Then I spent a few hours last week debugging a memory corruption issues that was due to using
self.displayName = name
in some places and
displayName = name
in others. I was happy when I found it and my app stopped crashing. I wasn't so happy that I wasted several hours looking for such an avoidable mistake.
I use #defines more often where I should be using const declarations.
Also, I'm probably a little too prolific in the NSNotifications I throw around; decoupling run amok!
Bad habit: Retaining my Java mindset.
My Java background leads me to obsessively check for a null before even thinking about doing anything with a variable, when I could be making use of Objective-C's ability to send a message to nil. (See: "Sending a message to nil?")
Instead of trying to preemptively catch a nil, I have to remind myself that Objective-C allows me to simply write code that gracefully works with return values of 0 or nil.
Hard-coding strings like buttons/view titles. Pure lazy. Now need to get out everything in order to support localization :(
You mean, apart from grinning smugly when I can do in ten lines what takes an MFC coder 300? I suppose my biggest gripe about my own code is the explosion of accessors; next design work I do, I've set myself the challenge of using the smallest number of properties.
Misusing Bindings to bind model object properties to each other. This use of Bindings leads to code that is hard to understand, hard to debug, and hard to test. Use Bindings only to bind a UI to a Controller. If you need decoupled models, use NSNotification instead of bindings. At least it's a bit more explicit than KVO.
I learned to hate Interface@#$%-er back when it was far less useful and more buggy than it is now, and so tend to create all my UI in code, steadfastly still avoiding IB. It's silly, since I know it reduces my productivity a ton, but I just can't seem to be bothered to spend an afternoon learning how to plug things into IBs. (Yeah, I know how to do the simple stuff, but I always get annoyed when there's some medium-not-simple stuff to do, and IB seems to work against me.)
Ok, you convinced me -- I'm going to break THAT bad habit this weekend.
Thanks! :)
1) When using private global variables, start them with underscores and put them in the interface portion of the .m file like so:
@interface MyViewController (){
NSArray *_tableData;
NSNumberFormatter *_numberFormat;
}
2) Only use @properties for global public variables and/or interface elements.
3) Synthesize the global publics and call them by name.
4) Call your interface elements with self.labelTitle NOT _labelTitle.
The main reason I use these variable naming conventions is because I can easily look at a variable and know what it's used for and its scope, but mainly it's a work around for the bug in XCode where you try and refactor -> rename a variable across the project and it doesn't work in certain circumstances outside of this convention.
I refactor my variable names A LOT and this system alleviated a lot of the problems for me.
Other Quick Tips:
These are just off the top of my head. Of course, some people may disagree with what I wrote but these habits worked for me when I was getting started.
This is somewhat generic and not necessarily cocoa specific but:
Not refactoring enough because the laziness of having to update both .m and .h files.
XCode 3 makes it easier for certain kinds of refactoring like renames, but I found myself refactoring less frequently than on Java or C# and that's a bad habit I'm trying to break.
I often find myself forgetting to type the return self; part of my constructors. Luckily I've begun to break this particular habit.
