Contributing to LISA
====================
First of all, if you’re reading this, thanks for thinking about
contributing! This project is maintained by us Arm folks, but we welcome
contributions from anyone.
How to reach us
---------------
If you’re hitting an error/bug and need help, it’s best to raise an
issue on github.
Coding style
------------
As a rule of thumb, the code you write should follow the
`PEP-8 `__.
We strongly recommend using a code checker such as
`pylint `__, as it tracks unused
imports/variables, informs you when you can simplify a statement using
Python features, and overall just helps you write better code.
Documentation
-------------
Docstring documentation should follow the ReST/Sphinx style. Classes,
class attributes and public methods must be documented. If deemed
necessary, private methods can be documented as well.
All in all, it should look like this:
.. code:: python
def foo(a, b):
"""
A one liner description
:param a: A description for param a
:type a: int
:param b: A description for param b
:type b: str
Whatever extra description you might over as many lines as you need
(but be reasonable)
"""
pass
Tests
-----
You should strive to validate as much of your code as possible through
self-tests. It’s a nice way to showcase that your code works, and also
how it works. On top of that, it makes sure that later changes won’t
break it.
Have a look at `the
doc `__
for more info on LISA self-tests.
Commits
-------
As for the shape of the commit, nothing out of the ordinary: just follow
the good old 50/72 rule (it’s okay if you bite off a few extra chars).
The header should highlight the impacted files/classes. The ‘lisa’
prefix can be omitted - for instance, if you’re modifying the
``lisa/wlgen/rta.py`` file, we’d expect a header of the shape
``lisa.wlgen.rta: ...``.
When in doubt, have a look at the git log.