Conventions and Guidelines

Symfony Conventions:

Structure

• Add a single space after each comma delimiter
• Add a single space around operators (==, &&, ...)
• Add a comma after each array item in a multi-line array, even after the last one
• Add a blank line before return statements, unless the return is alone inside a statement-group (like an if statement)
• Use braces to indicate control structure body regardless of the number of statements it contains
• Declare public methods first, then protected ones and finally private ones.
• Add full stops at the end of each line in your documentation or Alaa will make fun of you in the evaluations. Also remember to use a capital letter for String in the documentation and not a small letter (string is wrong).

Naming Conventions

• Issue : S[StoryNumber]:StoryTitle

Example: `S13: As a user I can register`

• Branch Name: ComponentNumber_userName_#StoryNumber_short_title

Example: `C2_EslamMaged_#13_RegistrationProcess`

Commit Message

• Infinitive verbs. Example (Change, Modify, Add) NOT ( Changed, Changes, Adds, Added )
• A one line message describing what you did

Example: `Issue #XXX - Add the UI for the registration process`

Code Styles and Conventions:

In case your code doesn't look cool. The reviewer has the full right to refuse PART/ ALL the code till it meets our cool criteria.

Our Cool Criteria for well formatted code

First things first

In netbeans [For the backend]: use Alt + Shift + F after selecting the whole text In eclipse [ For the frontend]: Use Ctrl + Shift + F after selecting the whole text

Indentation and Whitespaces

The IDE will help you with that if you followed the commands in 'First things first' section

PHP Conventions

• Variables names are descriptive

Example:
`$x = 5;` // BAD CODE
`$age = 5;` // GOOD CODE

• Methods: (Number of lines in a method never exceeds 50 lines)

Example:
`this_is_a_method();` // BAD CODE
`thisisamethod();` // BAD CODE
`thisIsAMethod();` //GOOD CODE

• Classes:

`foobar` //BAD CODE
`FOOBAR` //BAD CODE
`FOO_BAR` //BAD CODE
`FooBar` //GOOD CODE

• Code Commenting: There shouldn't be any comments next to your code unless its really important.

Documentation

    /**
     * [sendMessage description]
     * @param  [type] $userid  [description]
     * @param  [type] $message [description]
     * @return [type]          [description]
     */

Example:

   /**
    * this sends user with userID a message
    * @param  Int $userid  user ID
    * @param  String $message None
    * @return None
    * @author shaban
    */
    public function sendMessage($userid, $message)
    {

    }

use /** then enter it will generate most of the documentation for you ;)

Reviewing

Implementation Reviewer

S/He checks for how the code looks

Scenario Reviewer:

S/He tests the codes by trying all the possible scenarios

Documentation Reviewer:

He checks how well the code is documented. Documentation part explained above. Also check that there does not exist commented code. (in line comments should be avoided unless the code is not that obvious. Otherwise, code must be descriptive and crystal-clear)

Communication

Main way of communication is our mailing list and the GitHub issue Tracker.
Please do not spam your co-workers(No jokes, no arabic, no offense)

Most of this page was inspired by Coolsoft-13