Cocoa Training Module 3

							
Introduction to Cocoa
Application Development
Module 3: IS&T Development Standards




All Materials © 2008 Apple Inc. All Rights Reserved.
Cocoa Coding Standards
 ■ Core Cocoa standards established by Apple
   -   Read All of The Objective-C Programming Language
       -   Naming Conventions

   -   Read All of Cocoa Design Patterns
       -   Model-View-Controller Design Pattern
IS&T Coding Standards
 ■ Based on Core Cocoa Standards
 ■ Expected of All IS&T Cocoa Framework
   Application Developers
   -   Technical Lead should review deviations with IS&T Cocoa
       Frameworks Manager (Kevin Ferrero)

 ■ See IS&T Cocoa Application Coding Standards At
   Apple document
   -   Available at http://istdev.apple.com/
IS&T Coding Standards (ctd.)




 ■ Localization Considerations
   -   Assume your app will be localized at some point

   -   Follow Guidelines in Localization Chapter in Xcode Help

   -   Don’t embed hard coded strings in code; instead use
       NSLocalizedString( ) functions
IS&T Coding Standards (ctd.)

 ■ All Compiler Warnings must be fixed prior to CVS
   check-in
   -   Clean and Build before check-in to ensure all warnings are
       resolved

   -   For additional information: http://developer.apple.com/tools/
       xcode/staticanalysis.html

 ■ Code Formatting
   -   Use Two Blank Lines In Between Method Definitions in .m files
IS&T Coding Standards (ctd.)

 ■ Code Formatting
     -     Blocks should be indented one level
 CORRECT

 -(void)myMethod:(NSArray*)myArray

 {
     if ([myArray count > 0])
     {
             // Do something
     }
 }

 INCORRECT

 -(void)myMethod:(NSArray*)myArray

 {
 if ([myArray count > 0])
 {
     // Do something
 }
 }
IS&T Coding Standards (ctd.)
 ■ Code Formatting
    -      Opening/Closing Braces should always be at the beginning of
           the line and aligned with the outer block
 CORRECT

 if ([myArray count > 0])
 {
     // Do something
 }

 INCORRECT

 if ([myArray count > 0]) {
     // Do something
 }
IS&T Coding Standards (ctd.)

 ■ Code Formatting
    -      Use Braces for Single-Line Blocks
 CORRECT
 if ([myArray count > 0])
 {
     NSLog(@”Array count = %d”, [myArray count]);
 }

 INCORRECT

 if ([myArray count > 0])
     NSLog(@”Array count = %d”, [myArray count]);
IS&T Coding Standards (ctd.)

 ■ Naming Conventions
    -      Name should infer the purpose of the item

    -      Do not use abbreviations except Application Prefix

    -      Use camelCase for ivar and method names
 CORRECT

 -(void)calculateAverage:(NSArray*)myArray;

 INCORRECT

 -(void)calcAverage:(NSArray*)myArray;

 -(void)calculate_Average:(NSArray*)myArray;

 -(void)calculateAvg:(NSArray*)myArray;
IS&T Coding Standards (ctd.)
 ■ Naming Conventions
     -     Names of non-IBOutlet ivars should should be prepended with
           an underscore
 CORRECT

 @interface MERFormDefinition : NSObject {

     NSString *_formTitle;

     IBOutlet NSTextField *formTextField;

 }


     -     IBOutlets do not need accessors

     -     Class Names should not be camelCase. Instead use
           Application Prefix followed by name using initial caps (eg.
           ESPTicketDefinition).
IS&T Coding Standards (ctd.)
 ■ Public vs. Private Methods
   -   Methods should generally be public

   -   Methods can be private if they are not suitable to be used by
       other classes

 ■ Public vs. Private Classes
   -   Classes can be made private to indicate they should not be
       used outside of the Framework or Project (eg.
       ELIBBundlePrivate)

   -   Respect the privacy of private classes and methods to insulate
       yourself from future changes in class design

   -   Seek Framework Team approval before calling Private
       methods or classes
IS&T Coding Standards (ctd.)

 ■ Maintaining HeaderDoc
   -   HeaderDoc is to be written for every file, class and method
       provided in a header file

   -   Should provide clear definition of the item and its purpose

 ■ Commenting Code
   -   Following naming conventions and providing HeaderDoc in
       acceptable quality reduces the amount of comments required

   -   Any code block which is unusual or moderately complex
       should be commented.
       -   Always comment threaded or recursive methods
IS&T Coding Standards (ctd.)
 ■ Commenting Code
   -   Document changes made for enhancements or bug fixes using
       the Radar bug ID, date, initials of the developer, and a short
       statement of the issue to be resolved

   -   Always use // notations for inline comments

 ■ Use of id
   -   id is generally not appropriate except in the “init...” methods
       for objects

   -   Defeats compile time type-checking and reduces code
       readability
IS&T Process Standards
 ■ Download from IS&T Developer Connection Web
   Site
   -   Documentation->Policies and Procedures->ISTCocoa
       Application Development Process

   -   File is ISTCocoaDevProcess.pdf