Coding Guideline

##General

1. Brackets should be on another line for better code-reading purposes

class Foo extends Model {  
    public function shoot(&$bar)   
    {  
        // shoot bar  
        if ( $bar->alive() )  
        {  
             $this->shoot($bar);  
        }  
        else  
        {  
             $bar->revive();  
        }  
    }  
    // and so on....  
}  

2. Long codes (≥ 250 lines), need to be separated to components. Functions longer than 100 lines of codes should be broke into sub-functions.

3. Do not forget to do documentations for the code that you have done. The more comments the better.

4. Shorter code is not always better. Always keep in mind the runtime of your algorithm (e.g. Merge sort has better runtime than Bubble sort but it has longer code).

5. Commit testings in another branch and make sure it works correctly before you merge it to the master branch.

6. Layout partials are handy. Use them if necessary, especially when you are use a certain html code in multiple layouts.

##Variable Naming

1. Use readable, easy-to-identify names for variable names. Be very explicit with your variable naming, but also compact and short. The word "concentration" or "distribution" is long, but that doesn't mean you should shorten the word. Just keep it as explicit as possible for easy code-reading purposes.

2. Do not use CamelCase (i.e. obedJosiahTandadjaja or appleOrangeFruit). For consistency purposes I have decided to use ansi_style (i.e. separate two words with an underscore; obed_josiah_tandadjaja or apple_orange_fruit). However, CamelCase should be used if convention requires it.

##Naming Conventions

1. Database: table names should be in plural form and in ansi_style

2. Database: column names should be in singular form and in ansi_style

3. Model: models should be in singular form and in CamelCase

4. Controller: controllers should be in plural form and in ansi_style

##Database

1. 4NF or BCNF

2. Column names should be as explicit yet as compact as possible.