Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
72 changed files
with
1,602 additions
and
524 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,43 +1,51 @@ | ||
| # Contributor Covenant Code of Conduct | ||
|
|
||
| ## Development idea | ||
|
|
||
| - Write extremely clean, simplify and graceful code. Fully agree with <Refactoring: Improving the Design of Existing Code> and <Clean Code: A Handbook of Agile Software Craftsma>. | ||
|
|
||
| ## Code push conventions | ||
|
|
||
| - Make sure all test cases passed. | ||
| - Make sure test coverage not lower than dev branch. | ||
| - Use checkstyle to check code style, provide special reason if rule violated. Find checkstyle template from `sharding-sphere/src/resources/sharding_checks.xml`, please use checkstyle 8.8 to run the rule. | ||
| - Make sure `mvn clean install` can be success. | ||
| - Delete unused code in time. | ||
|
|
||
| ## Code Conventions | ||
|
|
||
| - Use linux line seperator. | ||
| - Indent (including blank lines) is consistent with the previous line. | ||
| - No unnecessary blank line. | ||
| - All logs and java docs are in English. | ||
| - Commit allow javadoc, todo and fixme only. | ||
| - Give a meaningful variable name. The name of return value is result; The name of unit value is each in for each sentence, instead of entry for map iterator. | ||
| - Name of properties file is camel-case, first letter is lowercase. | ||
| - Constant on left and variable on right in conditional expression. | ||
| - The nested loop should extract to a new private method. | ||
| - Replace Nested Conditional with Guard Clauses. | ||
| - Access permissions for classes and methods should minimal as possible. | ||
| - Parameters and return value are not allowed to be null. | ||
| - If use comment to explain the code, try to split several small methods, and use method name to explain it. | ||
| - Use lombok instead of the constructor, getter, setter methods and log variable. | ||
| - keep style consistent with existed code. | ||
| - No duplicate code and configuration. | ||
|
|
||
| ## Unit Test Conventions | ||
|
|
||
| - Test code and production code equality, should follow the same code conventions. | ||
| - Test cases should fully covered if no special reason. | ||
| - Separate environment preparation codes and test codes. | ||
| - Only junit Assert, hamcrest CoreMatchers, Mockito related can use static import. | ||
| - For single parameter assert, should use `assertTrue`, `assertFalse`, `assertNull` and `assertNotNull`. | ||
| - For multiple parameters assert, should use `assertThat`. | ||
| - Assert accurately, do not use `not`, `containsString` and so on. | ||
| - Use actualXXX and expectedXXX to name related variable. | ||
| ## Development Concept | ||
|
|
||
| - Write codes with heart. Pursue clean, simplified and extremely elegant codes. Agree with concepts in <Refactoring: Improving the Design of Existing Code> and <Clean Code: A Handbook of Agile Software Craftsmanship>. | ||
| - Be familiar with codes already had, to keep consistent with the style and use. | ||
| - Highly reusable, no duplicated codes or configurations. | ||
| - Delete codes out of use in time. | ||
|
|
||
| ## Contributor Covenant Submitting of Conduct | ||
|
|
||
| - Make sure all the test cases are passed, Make sure `mvn clean install` can be compiled and tested successfully. | ||
| - Make sure the test coverage rate is not lower than the dev branch. | ||
| - Make sure to check codes with Checkstyle. codes that violate check rules should have special reasons. Find checkstyle template from `sharding-sphere/src/resources/sharding_checks.xml`, please use checkstyle `8.8` to run the rules. | ||
|
|
||
| ## Contributor Covenant Code of Conduct | ||
|
|
||
| - Use linux line separators. | ||
| - Keep indents (including blank lines) consistent with the previous one. | ||
| - Keep one blank line after class definition. | ||
| - No meaningless blank lines. | ||
| - Use meaningful class, method and variable names, avoid to use abbreviate. | ||
| - Return values are named with `result`; Variables in the loop structure are named with `each`; Replace `each` with `entry` in map. | ||
| - Exceptions when catch are named with `ex`; Exceptions when catch but do nothing are named with `ignored`. | ||
| - Name property files with camel-case and lowercase first letters. | ||
| - Have constants on the left and variable on the right in `=` and `equals` conditional expressions; Have variable on the left and constants on the right in `greater than` and `less than` conditional expressions. | ||
| - Use `LinkedList` in priority. Use `ArrayList` for use index to get element only. | ||
| - Use capacity based `Collection` such as `ArrayList`, `HashMap` must indicate initial capacity to avoid recalculate capacity. | ||
| - Design class as `final` class expect abstract class for extend. | ||
| - Make nested loop structures a new method. | ||
| - Use guard clauses in priority. | ||
| - Minimize the access permission for classes and methods. | ||
| - Private method should be just next to the method in which it is used; writing private methods should be in the same as the appearance order of private methods. | ||
| - No `null` parameters or return values. | ||
| - Split codes that need to add notes with it into small methods, which are explained with method names. | ||
| - Replace constructors, getters, setter methods and log variable with lombok in priority. | ||
| - Use English in all the logs and javadoc. | ||
| - Include Javadoc, todo and fixme only in the comments. | ||
| - Only `public` classes and methods need javadoc, other methods, classes and override methods do not need javadoc. | ||
|
|
||
| ## Contributor Covenant Unit Test of Conduct | ||
|
|
||
| - Test codes and production codes should follow the same kind of code of conduct. | ||
| - Without particular reasons, test cases should be fully covered. | ||
| - Environment preparation codes should be separate from test codes. | ||
| - Only those that relate to junit `Assert`, hamcrest `CoreMatchers` and `Mockito` can use static import. | ||
| - For single parameter asserts, `assertTrue`, `assertFalse`, `assertNull` and `assertNotNull` should be used. | ||
| - For multiple parameter asserts, `assertThat` should be used. | ||
| - For accurate asserts, try not to use `not`, `containsString` to make assertions. | ||
| - Actual values of test cases should be named `actualXXX`, expected values `expectedXXX`. | ||
| - Class for test case and `@Test` annotation do not need javadoc. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.