Consequences of disregarding naming conventions


#1

The section on Initializers (page 47) includes this rather ominous text:

Can anyone provide an example of the type of problem referred to here? Or is the Objective-C community simply filled with conformists looking to scare other people into conforming? :wink:


#2

Consider you decide to prefix all your initialization methods with “start” rather than the convention "init"
Now u write another class and decide to prefix it with "begin"
And ur next one the mood strikes u to go with "theGreatestInitPrefixEver"
Hopefully u can understand what a headache it will be remembering what your initialization methods are called.
Now lets say u flesh out and add to these classes then publish them for others to use in a set of API’s. Now u pass an even worse headache on to anyone who wants to use your API’s as they all expect that u have honored proper naming conventions and prefixed all initializers with init

So it is your choice if u respect naming conventions, the compiler won’t care and ur code will run but ur coworkers or anyone else who is using that code will be needlessly frustrated.

In the same vain, say u work on a project w/a number of other programmers, u agree to certain conventions in the way u write, or style, your code. For ex the way u comment your methods in your header files. Obviously there r innumerable ways to describe what your method does, but agreeing on a common convention saves people the time of first figuring out where the information they are looking for is, then actually consuming that info as illustrated in the example below

// Summary: This method searches the string for the data that we want in a...
// Arguments: Pass in the string to be searched
// Returns: The AI answer to the sentence in a NSString or nil if no answer possible
- (NSString *)someSuperPowerfulArtificalAnswerCreater:(NSString *)searchThisString;

#3

Yes, using inconsistent naming conventions will make things unnecessarily difficult and annoying for users of my code, but I don’t think they justify the book’s description of “problems that are worse that most beginners would imagine.” I’ve been coding professionally for decades. When I read a warning like that, I expect dire consequences, like random program behavior or the device hanging or shooting out sparks or something.

Recently, I encountered the need to follow a naming convention so that a generated XIB file would accurately match its associated components. Perhaps that type of thing is what the author is referring to. ???


#4

If u add a methods to existing frameworks via categories, convention says u should prefix those methods with something like your initials. e.g.

@interface UIFont (MySweetAdditionToThisExistingFramework)
+ (id)dbs_myCustomFontWithSize:(CGFloat)size;
@end

If u choose not to perform this conventional step, you may inadvertently name your method identically to a private Apple one, resulting in your method being called in lieu of Apple’s perhaps causing your mac to catch on fire, or crash your program, or cause a inexplicable bug…
Furthermore, if u dodged that mine for now, Apple could at any time introduce a method that indeed shares the signature of yours causing your app to go haywire upon an iOS update.

When using Core Foundation, if a function name contains the word Create or Copy, u own the object and must balance it with a CFRelease(obj); function call, to free the memory.

On a more esoteric note, sooner or later u may work on code destined for versions of iOS that don’t support ARC. In those cases if u do not understand the naming conventions for memory management your app will likely crash one way or another (& it will be a hellacious experience figuring out why). Either through memory leaks or accessing bad memory via a dangling pointer. The convention is objects created by methods other than alloc and copy get sent autorelease before being returned and it is up to u to manually retain them if u need them after the pool gets flushed. If u get an object through alloc or copy u are required to release it or u leak.

So if u decide to go rogue on the naming conventions and return an object that is not autoreleased in a method u define that doesn’t have alloc or copy in its name, how would u know u need to release that object? It would take more than reading the method name, presumably. Of course u could adopt ur own naming system, but to what end?