Hacking guide

rockiger edited this page Oct 5, 2017 · 4 revisions

Style Guide

  • 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.