Hey Contributor! 😺
All contributions to PHPSA are very much encouraged, and we do our best to make it as welcoming and simple as possible.
We require that all contributions meet at least the following guidelines:
- Follow PSR-1 & PSR-2
- Use camelCase for variables and methods/functions.
- Don't use functions for casting like
intval
,boolval
and etc, We are using(int) $a
. - Avoid aliases for functions:
sizeof
,join
and etc. - Avoid global variables.
- Avoid strict comparisons if not necessary.
- Avoid
static
methods. - Only use
static::
binding if it's really needed.parent::
orself::
will be sufficient in most cases. - Don't use
Singleton
pattern anywhere. - Use strict types (objects, arrays); for example:
function testMethod(array $array = [])
. - Use
$v === null
instead of 'is_null()' for null checking. - Avoid "Yoda conditions", where constants are placed first in comparisons:
if (true == $someParameter) {
}
- Don't forget about empty lines after logical blocks:
public function simpleMethod($a)
{
$result = 1 + 2;
// $result is not related to if block, please write empty line
$b = $a;
if ($b) {
$result = 1;
}
// Empty line is needed there
return $result;
}
ATTENTION Some rules can be omitted in tests/analyze-fixtures
, because we need to check Analyzers on bad code.
- For
abstract
classes, useAbstract
prefix,AbstractCondition
- For
trait
(s), useTrait
suffix,ResolveExpressionTrait
- For
interface
(s), useInterface
suffix,PassFunctionCallInterface
- For any classes that extend from
Exception
, useException
suffix,UnknownException
Please omit s
at the end of NS/Class/Trait/Interface names
What we are using:
\PHPSA\Analyzer\Helper\ResolveExpressionTrait
What we don't use:
\PHPSA\Analyzer\HelperS\ResolveExpressionSTrait
Please don't use "merge" in your PR, we are using "rebase", small guide:
Example:
git checkout YOUR_BRANCH
git fetch upstream
git rebase upstream/master
git push origin YOUR_BRANCH -f
This assumes you have configured the upstream remote like this:
git remote add upstream https://github.com/ovr/phpsa.git
We are using Makefile:
# running unit tests
make tests
# running code style check
make cs
# running all checks (CI)
make ci
# updates configuration and documentation files when analyzers were changed/added
make analyzers
- If you are going to close an issue, write a comment describing why you are going to do so (with link reference to the commit/issue/PR)
- Before merge, check that CI passes
- Merge after review (1 other developer reviewed)
- Check that code uses our
Coding Standards
andNaming Conventions
- Don't merge big PRs (only simple PRs), if it's a big PR - please ping @ovr
- Write
Thanks
to developer(s) and reviewer(s) after PR was merged - If there are any
merge
commits in PR, you should write a notice to the submitter to remove those
Thanks 🍰