Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

minor updates to contribution guide in code guidelines part #1286

Merged
merged 1 commit into from
Feb 19, 2024
Merged

minor updates to contribution guide in code guidelines part #1286

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -102,17 +102,17 @@ Make sure your contribution is aligned with Passage project code guidelines.
In the latter case implementation must actively fail.
* Use _fail fast_ approach when handle incorrect input data. Do not make assumptions, do not built-in fallback strategies.
* There must be no _static_ methods or fields in your class, unless it is directly demanded by an external framework.
* For all local variables and class fields neither cameCase nor snake_case is applicable, compound names are prohibited.
* For all local variables, method parameters and class fields (anything at all that carries data) neither cameCase nor snake_case is applicable, compound names are prohibited.
* For all method _query/action_ naming approach must be used.
Query-method does not change the owning class state, returns a value and is named with a noun or adjective after the value it returns.
Action-method can change the owning class state, mainly does not return a value and is named with a verb after the activity it performs.
Sometimes action-method can return status, but there must be valuable reasons for such design.
* All fields in a class must be declared both _private_ and _final_, unless otherwise is directly demanded by a framework in use.
* All fields in a class must be declared both _private_ / _protected_ and _final_, unless otherwise is directly demanded by a framework in use.
* Constructor must not perform any calculation, only assignments.
* Designing a class hierarchy apply _either final or abstract_ approach. It concerns not only class inheritance itself but also each piece of implementation. Class must be declared either _abstract_ or _final_. Each method in an _abstract_ class must be declared either _abstract_ or _final_ or _private_. Implementation inheritance is totally prohibited in any form.
* No optimization, caching or other 'improvements'-alike solutions must be applied to a code unless it is proven there is a significant performance issue.
* A class must stay small and dedicated to a single aspect of a domain. Methods must stay small and do exactly one thing as well.
* Keep code granularity on the same level across a single scope.
* Keep code granularity on the same level across single scope.

Make sure your code is sufficiently covered with tests.

Loading