as discussed with some members of the Community and Association, we plan to establish Code Contribution Guidelines.
I created this shared Microsoft Word file and added some initial ideas:
I am happy to collect more ideas/guidelines from the Community - either here in the thread or directly in the file. Ideally we will add examples for each point and eventually publish it on OpenEMS Docs (Introduction :: Open Energy Management System)
It’s also helpful to look at existing examples in the open source world:
I like the idea very much. It helps us having more consistent code and makes it easier for developers to read and understand code of other developers.
I would suggest updating PR1006 and add the points from your documentation. This could be the very first start for general OpenEMS code contribution guidelines.
Also I would like to add another rule, because I see often some ‘beginner’s mistakes’:
Be sure you do not use code which blocks
handleEvent() methods of an OpenEMS component.
Also I am concerned about another class of mistakes, where I do not see a general rule for. The interface between UI and edge/backend. It is best explained on the Configuration of chargepoints. The Zoe Option in the UI expects a function
config.minHwCurrent() which must be given in ‘mA’. If the UI option is triggered it changes this configuration setting. It is not intuitive clear, that
minHwCurrent() is expected to be in ‘mA’. And it is not easy to find during the tests if you do not have a Renault Zoe. It has collided with our implementation of some new chargepoint models which expect
minHwCurrent() being given in ‘A’.
Unfortunately, due to OSGI mechanisms, we can not put an interface on each EVCS configuration. I have no idea how to approach this class of errors so far.
Nevertheless, OpenEMS Code Contribution Guidelines can be very useful in joint collaboration.