HACKING

/*
    File: HACKING
    Description: The Goonj hacking and code standards.

    This file is part of Goonj.

    Goonj is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    Goonj is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with Goonj. If not, see <http://www.gnu.org/licenses/>.

    Copyright 2009 Pratul Kalia.
    Copyright 2009 Ankur Sethi.
*/

////
General formatting
////
- Each file has the GNU GPLv3 license header on the top. If you add code to a
  particular file, you should add your name to the Copyrights at the end of the
  license header. Put your full name and please see that the list is sorted via
  last name.

- Indent all code using 4 spaces only. No tabs.

- The header of each file must contain the file name and a small description of
  what the file does.

- All files that are imported should be right at the top of the header files.
  OS X frameworks should be mentioned first, and then other project specific
  files. For example:

    #import <Cocoa/Cocoa.h>
    #import <CoreData/CoreData.h>
    #import "GAppController.h"
    #import "GTrack.h"

   Headers must be sorted alphabetically.

- Give a gap of 2 lines between the license header and the file imports. Also,
  a gap of 2 lines between the file imports, and the code.

- It is recommended you use Google Toolbox For Mac Xcode Plugin. It smartly
  removes trailing whitespaces from files when they are being saved. Get it from
  http://code.google.com/p/google-toolbox-for-mac/wiki/GTMXcodePlugin

////
Classes
////
- Class definitions in a header file must have the opening brace "{" in the same
  line as the name line.

- Always list the instance variables before the IBOutlets. If required for
  readability, you may separate the instance variables and IBOutlets with a line
  and an optional comment.

- The closing brace of the @interface block should be on a new line.

- There should be a gap of one line before you start the method definitions.

- While defining methods for a class, the parameters passed in the method should
  have an article like "a" or "an" before them (for example: aURL, anInstance)

- The method definitions should be in the order: Own methods, delegates and then
  IBActions. The names should be written with one space after the -/+. There
  should also be one space between the ")" of the return type and the method name.
  For example:
    - (NSInteger) numberOfRowsInTableView:(NSTableView *)tableView;
    + (id) someFooBar;

- Constants should start with "k", like kDateOfBirth or kFathersName.

- #pragma marks should have a line of "////" (4 backslashes), before and after
  the #pragma mark itself.


////
Methods
////
- Method names should have one space after the -/+. There should also be one
  space between the closing ")" of the return type and the method name.

- Both, the opening and closing parenthesis, of all the methods should be on
  their own lines.

- Many times, method names exceed the 80-character guide. In such a case, you may
  line break parameters into the next line.

////
Variables
////
- Method parameters are named with a prefix of 'a' or 'an'. For example, aTableView and anEvent.
- Local variables are named with a prefix of 'the'. For example, theTableView and theEvent.
- Loop variables don't need a prefix. For example:
    for (NSTableColumn *column in [theTable columns])
        // some code.
- Instance variables don't need a prefix.