Hacking guide
rockiger edited this page Oct 5, 2017
·
4 revisions
- Follow PEP 8
- Lines up to 120 characters
- Indent with 4 spaces
- UpperCamelCase classes and settings in the config
- lowerCamelCase variables and methods
- alllowercase modules and packages
Public core modules and classes shall be very well documented as an API for plugin creators. Non-API methods and classes shall not be included to auto-generated documentation.
Other code (plugins and internal core code) is not included to auto-generated documentation, but still has to be documented to improve readability and simplify support.
Follow PEP 257 Docstring Conventions, but:
- Do not put blank line between a class header and a class docstring
- Summary line may be omitted in multiline docstrings
- Period may be omited at end of singleline docstrings
- We don't have any paid QA engineers. (And generally, no any stuff ;) )
- Already now Enki is quite big.
- Enki is not stable. It changes often. All code changes, including core API.
- Even me (hlamer, the author) do not use all Enki features. It is impossible to test manually all functionality after changes has been made.
- Enki is going to grow quickly. We don't want to be afraid of changes.
- Enki declares High Quality on the first page. We are not going to release broken code.
Yes, I know that you don't like writing tests, but it is MUST. First version didn't have any tests. But currently all new and modified code is covered with tests.
- Follow Zero defects metodology (paragraph 5)
- Create screencasts with Screenkey (not mandatory)