Code Organization and Standards

gistfile1.txt

Functions/Methods
    Should do one thing and one thing only
    Should not be longer than 30 lines (if possible, most of the time the expections are large switch statements)
    Single lines should not exceed screen width
    Any unused functions should be removed
    Method names should be self explainatory
    No side effects!
        Yes, these means we don't override getters and setters.
    Functions should follow 'the golden path'. Which means the developer minimizes nested code by 'returning' instead of using if else statements.
    For more guidelines refer to this document: https://github.com/raywenderlich/objective-c-style-guide
    
Classes
    Should be responsible for 1 thing.
    Most NSDictionarys can and need to be converted to classes.
    Do not expose Data (properties)
        This is to avoid the 'bean' class design.
        Object oriented classes need to be told to do something, and not act as data (which is more like procedural programmings, we're OOP programmers).
        This helps avoid train wrecks!! Ex: self.networkController.urlcache.lasturl.urlAsString.stringWithoutPrefix;
        The above example would be ok if each property was a class of only data without functions (still not OOP though).
    Minimize function parameters and return values.
        More parameters increases the complexity of the function.
        More parameters is more confusing the the developer.
        More parameters is a sign that your function may do more than on thing.
    Class variables should be used in most of that classes functions
        if it is not then its a sign that you can split your class up into two classes.

Comments & Documentation
    No comments or documentation explaing 'how'.. thats for the code to explain.
        This minimizes misleading documentation becase 'how' changes frequently.
    Comments are a good indicator that code should be refactored to be more self explainatory!
    Commented out code should be deleted
        If you need the code later retrieve it with GIT
    Document any 'hack' along with why and how it works, and, if possible a solution, to remove the hack
    Document anything that is not self-explanatory
    If we're creating an 'api' for seperate program, This api should be fully documented (Params, return values, everything).
        Refer to apple's api documentation for a similar example.
    Documentation is done in Header2Doc format

Testing:
    Though this project has no tests at the moment we should follow BDD (behavior-driven development)
        refer to this wiki: http://en.wikipedia.org/wiki/Behavior-driven_development
    Before writing any code we should always follow this procedure:
        Design - Figure out how everything is going to work, dont just start coding.
        Test - Write failing tests for the code you want to write
        Code - Write the code to pass the tests
        Test - Pass the tests
    Write mostly unit tests and minimal integration tests
    What is a unit test?
        -Repeatable: You can rerun the same test as many times as you want.
        -Consistent: Every time you run it, you get the same result. (for example: Using threads can produce an inconsistent result)
        -In Memory: It has no "hard" dependencies on anything not in memory (such as file system, databases, network)
        -Fast: It should take less than half a second to run a unit test.
        -Checking one single concern or "use case" in the system: (More than one can make it harder to understand what or where the problem is when the problem arises.)
    By breaking any of these guidelines, you increase the chance of developers either not trusting or not believing the test results (due to repeated false failures by the tests), or people not wanting to run the tests at all because they run too slowly.
    Why don't we like integration tests?
        -Be much slower than unit tests
        -Be much harder or time consuming to recreate and run fully
        -Collecting the test result might be more problematic
    When to use integration tests?
        -Written as an additional layer of regression testing beyond unit tests
        -In legacy code, written before unit tests or refactoring can be done