On 05/04/2011, at 10:48 AM, Carlos Eduardo Mello wrote: > Still, if you look at this little test app (public link to Google Docs), > you'll see what I mean. There is an AppController class, (which was made the > window's delegate) with an outlet connected to a text field and a button in > the window. The button calls an Action called 'setTextField', but the > 'textField' outlet is never available when the button is clicked. The outlet > wasn't wired, even though it is correctly connected in IB. Now if you change > the button's action name to fillTextField (or anything other than > setTextField), everything works ok -- the field is there waiting to be > accessed.
On a general note, you need to know who you're writing code for. A compiler is happy with all sorts of stupidly named stuff (notwithstanding the possibility of confusion caused by naming conventions that have a semantic meaning beyond their face value, as here). But humans are not compilers. You need to write code for humans. So what's wrong with naming an action 'blahblahblahAction'? It TELLS you it's an action. The compiler doesn't need that extra hint, but you'll be glad of it in all sorts of situations, especially years from now when you long since forgot what you were thinking when you wrote it. If you write a method set<Something>, it had jolly well better be a setter, and NOT an action. (This is one of those naming conventions that goes beyond face value anyway). I've recently done quite a bit of code porting and it's astonishing how little effort people put into making code self-documenting, even when the code is open-source and therefore intended to be seen by others, and even when there is no conventional documentation (which appears to be the norm, and something I'm very bad at myself). Making code self-documenting by a better choice of variable and parameter names, with a sprinkling of consistent conventions, is very little effort up front, and saves literally hours and hours of work later on. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
