Objective C: How to view code in iOS

Apple has developed a set of guidelines for how to write code for maximum clarity and integration with wireframes. In addition, there are some undocumented conventions that Cocoa developers often use.

Class names:

• Class names are always capitalized.

• Objective-C has no namespaces, so prefix your class names with initials. This avoids "namespace collisions," which is a situation where two pieces of code have the same name but do different things. Classes created by Cocoa Dev Central are likely to be prefixed with " CDC ".

• If you are subclassing the standard Cocoa class, it is recommended to combine the prefix with the superclass name, such as CDCTableView .

Variable names:

• Variable names start with lowercase letters, but are internally capitalized wherever a new word appears:

   NSString * streetAddress  = @"1 Infinite Loop";
   NSString * cityName       = @"Cupertino";
   NSString * countyName     = @"Santa Clara";
  
        
  
          
          
          
        
  
      

--------- Correct way ---------

     NSString       * hostName;
     NSNumber       * ipAddress;
     NSArray        * accounts;

      

        
        
        
      

    

--------- Wrong way ---------

     NSString       * HST_NM;      // all caps and too terse
     NSNumber       * theip;       // a word or abbreviation?
     NSMutableArray * nsma;        // completely ambiguous

      

        
        
        
      

    

2. Variables cannot start with a number, spaces, and special characters other than underscores.

3. Apple is moving away from using the underscore as a prefix for a private instance variable.

    NSString * name    // correct!
    NSString * _name   // _incorrect_
   
         
   
           
           
           
         
   
       

Variable names: pointer type

• In real-life terms, a variable name usually does not indicate a type unless it is something general, such as NSString, NSArray, NSNumber, or BOOL.

Right

     NSString       * accountName;
     NSMutableArray * mailboxes;
     NSArray        * defaultHeaders;
     BOOL             userInputWasUpdated;

      

        
        
        
      

    

Ok but not perfect

     NSString       * accountNameString;
     NSMutableArray * mailboxArray;
     NSArray        * defaultHeadersArray;
     BOOL             userInputWasUpdatedBOOL;

      

        
        
        
      

    

2. If the variable is not one of these types, the name should reflect it. Also, there are certain classes for which you only need one instance. In this case, just provide a variable based on the class name. The font manager is a good example of this.

When to specify the type

     NSImage             * previewPaneImage;  // self-explanatory
     NSProgressIndicator * uploadIndicator;   // shows progress for uploads
     NSFontManager       * fontManager;       // only one of these, basic name ok

      

        
        
        
      

    

Method names

• Methods are perhaps the most important topic we can talk about. Most object oriented languages ​​use syntax.

• While these method names are easy to write the first time around, the actual behavior is not clear. This is much more problematic among the sheer amount of surrounding code.

• Cocoa programmers think backwards, choosing a method name based on how it will look in real use. Let's say I want to write a memory file written to disk.

In Cocoa / Objective-C, it looks like this:

    [fileWrapper writeToFile: path atomically: YES updateFilenames: YES];

      

        
        
        
      

    

Method names: Accessors

• Unlike many other languages, Objective-C does not recommend using the "get" prefix for simple accessories. Instance variables and methods can have the same name, so use this to your advantage:

Right!

      - (NSString *) name;
      - (NSString *) color;

      name  = [object name];
      color = [object color];

      

        
        
        
      

    

Incorrect

      - (NSString *) getName;
      - (NSColor  *) getColor;

      name  = [object getName];
      color = [object getColor];

      

        
        
        
      

    

2. The "get" prefix is ​​used, however, in situations where you return a value indirectly via a memory address:

When to use the "Get" prefix

// copy objects from NSArray to buffer

      id *buffer = (id *) malloc(sizeof(id) * [array count]);
      [array getObjects: buffer];
      ( Don't worry if you don't know what malloc does. )
      The "set" prefix is always used on setters, though:


      [object setName:  name];
      [object setColor: color];

      

        
        
        
      

    

adjectives

• Not all accessors return values ​​like name, date, height, etc. Some of them represent especially the quality of the object. They are often represented by BOOLs .

• For example, "selectable". In Objective-C, the getter for this key is called -isSelectable, but setter -setSelectable:

      BOOL selectable = [textView isSelectable];
      BOOL editable   = [textView isEditable];
  
      [textView setSelectable: YES];    // no "is"
      [textView setEditable:   YES];    // no "is"
  
       // if textview is editable.
  
      if ([textView isEditable])
      [textView setEditable: NO];
  
        
  
          
          
          
        
  
      

• Keep in mind that naming your accessories according to all of these rules is not purely a matter of clarity and aesthetics. Cocoa relies heavily on KVC for most of its magic, while KVC relies on the correctly named accessors.

I think this will help you.