-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #18 from sharding-sphere/dev
update from origin
- Loading branch information
Showing
791 changed files
with
5,325 additions
and
3,294 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
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 |
---|---|---|
@@ -0,0 +1,43 @@ | ||
# 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. |
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 |
---|---|---|
@@ -0,0 +1,34 @@ | ||
You can report a bug, submit a new feature enhancement recommendation, or commit codes by a pull request. | ||
|
||
## Reporting Bugs | ||
|
||
- Before report a bug, please search from google to confirm you cannot find any hint on it. | ||
- Look [issues List](https://github.com/sharding-sphere/sharding-sphere/issues) to confirm this issue is not a duplicated one. | ||
- [Create](https://github.com/sharding-sphere/sharding-sphere/issues/new) a new issue. | ||
- Define a clear and descriptive title for the issue. | ||
- If bug reported, please provide information below: | ||
- Details for reproduce bug step by step. Include SQL, configuration, expected results, actual results and tracing log. | ||
- Sharding and Operation System version. | ||
- Source code to reproduce bug on github cna copy the link here. | ||
- Stack trace if exception thrown. | ||
- Screenshot and animated gif to help bug reproduce if necessary. | ||
- Screenshot for CPU, Memory, Network and IO stat if performance issue. | ||
- If enhancement recommendation reported, please provide information below: | ||
- Details for enhancement behaviour. | ||
- Explain why this enhancement is general feature for most developers. | ||
- List similar features which already available in other product if possible. Both open source and commercial software are available. | ||
- Assign label after create issue. Label should be bug, enhancement, discussion and so on. | ||
- Please pay attention on the issue and provide more information during discuss. | ||
- Please close issue when it is resolved. If you don't close it, we will close it after 3 days。 | ||
- If this issue has new information, please reopen it again. Please note, issue can reopen which only closed by yourself. If the issue is closed by us, you have no permission to reopen any more. | ||
|
||
## Commit pull request | ||
|
||
- Please choose a interested issue, or create a new issue and then settle a correct label. | ||
- Reply a deadline message to pickup this issue. | ||
- Find a mentor in [Core developers list](/en/organization/), he will give you feedback for design and implements. | ||
- Fork to your github repo and begin to work. | ||
- Please follow Sharding's [Development conventions](/en/contribute/convention/), and complete check before pull request submit. | ||
- Submit a pull request to dev branch when finished, please do not submit pull request to master. | ||
- Mentor will do code review and discuss some details, include design, implement, performance and code style. Code will be merged until mentor accepted. | ||
- Finally, congratulations that you have become the official contributor for Sharding! |
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
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.