| description |
|---|
General recommendation to bring meaningful contribution to the X-Cash Foundation. |
The following guidelines ensure that any contributor is able to bring thorough and documented additions to the code, as well as participate in the development of the X-Cash Foundation to bring success to the project. They are not an absolute requirement, but following these recommendations ensure that the pull requests and improvements can be reviewed, accepted and added to the core code.
These guidelines gives general recommendations into writing great and clean code. Following these standards are not a sine qua non condition to get your pull request validated, but it will definitely increase the likelihood.
Clean Code is a set of guidelines to have in mind to write meaningful and easy to navigate applications. The aim is to reduce the time, complexity, and cost it takes by new and experienced developers to review and maintain code.
The core characteristics of a clean code are the following. You should aim to meet as many of them with your code as possible.
- Clean code should be elegant - your code should be pleasing to read, and written with having in mind that someone else will read it.
- Clean code should be focused - Each class, function, module etc.. should have a single responsability and not be polluted by surrouding details.
- Clean code should be taken care of - Always keep it simple and ordered, so as to make it easier for the next developer.
A developer from the X-Cash Foundation, or another contributor will maintain your code; it is not a machine, please have this in mind. Pay attention to your formatting, variable naming and so forth to work toward a Clean Code.
Another set of principle to follow to ensure a well designed, flexible, testable and maintainable code is the SOLID pattern:
- Single responsibility principle - Every module or class should have responsibility over a single part of the functionality provided by the software.
- Open鈥揷losed principle - Software entities should be open for extension, but closed for modification.
- Liskov substitution principle - Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
- Interface segregation principle - Many client-specific interfaces are better than one general-purpose interface.
- Dependency inversion principle - One should depend upon abstractions, not concretions.