Archives
Categories

Coding Style and Guidelines

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.

  1. Start with the JIRA issue ID for the story or bug
  2. 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…”
  3. 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 into master in some time.
  • develop — this branch contains pre-production code. When the features are finished then they are merged into develop.
  • test — this branch contains testing server code. When develop branch codes are sent for testing then it merged to test 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 from develop and must merge into develop.
  • hotfix/* — hotfix branches are necessary to act immediately upon an undesired status of master. May branch off from master and must merge into master and develop.
  • 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 from develop and must merge into master and develop.

Notes: When you need feedback or help, or you think the branch is ready for merging, open a pull request