Coding Style and Guidelines
Overview
This document covers common coding styles and guidelines for INeedADevelopers project.
These guidelines try to cover both, the technical standards as well as giving incentives for a common development style. These guidelines must be followed by everyone who creates codes for this product.
Coding Guidelines:
- Namespace starts with vendor name followed by package key (name) and subparts as needed
<?php namespace Acme\TestPackage;
- One use statement per line. One use statement per namespace. Order statements alphabetically. Don’t import namespaces unless you use them.
use App\ArticleCategory; use Illuminate\Http\Request;
- No empty line between doc comment and class, member var, or method.
/** * Display a listing of the resource. * * @return \Illuminate\Http\Response */ public function index(Request $request) {
- Indent with spaces
- Multiline conditions: Indent them and add an extra indent to the following code. Put the boolean operators at beginning of the line
if (isset($someArray['question']) && $this->answerToEverything === 42 || count($data) > 3) { $this->fanOfFlow = true; } else { throw new \Exception('We cannot tolerate that.', 1223391710); }
- Opening brace on the next line
public function show($id) { // }
- Description of the class or function. Make it as long as needed, feel free to explain how to use it
/** * Here goes the description of the class. It should explain what the main * purpose of this class is... **/
- UpperCamelCase class name. Class names should be nouns.
- Method names should be verbs.
- Variable names are written in
lowerCamelCase
and should be- self-explanatory
- not shortened beyond recognition, but rather longer if it makes their meaning clearer
- Use repository pattern for development
- Use sentry for error monitoring.
- All credentials will be mentioned in the .env file.
Commit messages:
When committing code it is essential that others can quickly get an idea of what the commit relates to, and also find more information on the issue and review. A message must always be provided when committing to trunk, sustaining, or release branches/tags and we have some simple guidelines for writing them.
- Start with the JIRA issue ID for the story or bug
- State in up to 50 chars how this commit changes the product. Begin with a capital letter and don’t end with a full stop. Write as if completing the sentence “If applied, this commit will…”
- If you really need to provide further info in the commit message (info about the fix should be captured in the JIRA issue), then leave a blank line below the summary before adding the details.
Examples:
AME-9876 CR-1234 Add new authentication module for device auth
AME-9876 Add new authentication module for device auth
Branch Flow:
master
— this branch contains production code. All development code is merged intomaster
in some time.develop
— this branch contains pre-production code. When the features are finished then they are merged intodevelop
.test
— this branch contains testing server code. When develop branch codes are sent for testing then it merged totest
branch.
During the development cycle, a variety of supporting branches are used:
feature/*
— feature branches are used to develop new features for the upcoming releases. May branch off fromdevelop
and must merge intodevelop
.hotfix/*
— hotfix branches are necessary to act immediately upon an undesired status ofmaster
. May branch off frommaster
and must merge intomaster
anddevelop
.release/*
— release branches support preparations of a new production release. They allow many minor bugs to be fixed and preparation of meta-data for a release. May branch off fromdevelop
and must merge intomaster
anddevelop
.
Notes: When you need feedback or help, or you think the branch is ready for merging, open a pull request