All Projects follows the PSR-2 coding standard and the PSR-4 autoloading standard.
In this case the vendor namespace should be the app name;
In this case the vendor namespace it should be DMI\Services\
.
If it is a open source project, it should should have the vendor package as Descubraomundo
.
The class methods and properties must be in camelCase
like:
<?php
Class Invoice
{
protected $publicNotes = '';
public function getPublicNotes()
{
return $this->publicNotes;
}
}
All variables must be in snake_case
style like:
<?php
$email_marketing = 'example@test.com';
DocBlocks are divided into the following three parts. Each of these parts is optional, except that a Description may not exist without a Summary.
A DocBlock looks like this:
<?php
/**
* A summary informing the user what the associated element does.
*
* A *description*, that can span multiple lines, to go _in-depth_ into the details of this element
* and to provide some background information or textual references.
*
* @param string $myArgument With a *description* of this argument, these may also
* span multiple lines.
*
* @return void
*/
function myFunction($myArgument)
{
}
As we do not work with ActiveRecord(eloquent), it is fine to always pass an Object to the views and work with our entities.
For all the lang files, the keys should always be in english
and in snake_case
style like:
<?php
return [
'hello_world' => 'Hello World!'
];
All bug fixes should be sent to the latest stable branch. Bug fixes should never be sent to the master branch unless they fix features that exist only in the upcoming release.
Minor features that are fully backwards compatible with the current Project release may be sent to the latest stable branch.
Major new features should always be sent to the master branch, which contains the upcoming Project release.
If you are unsure if your feature qualifies as a major or minor, please ask Team Members.
Its recommended to use git extensions like gitflow to provide repository operations for Vincent Driessen's branching model.