Files
2024-03-17 11:39:27 +07:00

93 lines
2.6 KiB
Markdown

# Contributing Guide
Hey Contributor! :smiley_cat:
All contributions to SocialConnec are very much encouraged, and we do our best to make it as welcoming and simple as possible.
## Coding Standards
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.
* 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:
```php
if (true == $someParameter) {
}
```
* Don't forget about empty lines after logical blocks:
```php
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;
}
```
### Naming Conventions
#### Naming
* For `abstract` classes, use `Abstract` prefix, `AbstractCondition`
* For `trait`(s), use `Trait` suffix, `ResolveExpressionTrait`
* For `interface`(s), use `Interface` suffix, `PassFunctionCallInterface`
* For any classes that extend from `Exception`, use `Exception` suffix, `UnknownException`
## GIT
Please don't use "merge" in your PR, we are using "rebase", small guide:
[Git Branching Rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
Example:
```bash
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:
```bash
git remote add upstream [email protected]:SocialConnect/auth.git
```
## Testing
```bash
./vendor/bin/phpunit
```
## Maintaining (for push only developers)
- 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` and `Naming 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 :cake: