The objective of the FSM2 project is to provide a simple yet powerful Finite State Machine implementation.
Any project is only as good as its documentation.
A key objective of FSM2 is to provide quality documentation which makes it easy for both experienced and novices users to use the FSM2 package.
Development is to be done as a collaborative approach to problem solving.
New ideas should be started by raising an issue to give the community a chance to discuss the pros and cons of the proposed change.
The community should be supportive of all contributors and users and negative language will not be tolerated.
The dart code base will adhere the 'effective dart' lint rules.
Code MUST be free of errors and warnings before it will be accepted.
All code must be formatting using the standard dartfmt tool before it is submitted.
Code MUST be well commented.
All public API's must include examples code in the comments.
Careful consideration is to be given to what methods/class are exposed as part of the public api. The objective is to expose the smallest API possible.
Abbreviations in variable, method and class names should be avoided.
The code should attempt to adhere to conventions that are recognisable to the broader Flutter community and any recommended by the Google Flutter team.
Minimise included packages
Dart suffers from dll hell (where different package version from different dependencies conflict). To avoid being a source of dll hell we should aim to include the minimal set of package dependencies possible. We will have to balance this requirement with effort and long term maintenance issues.
ReCase is a good example. In reviewing the code base I found we had only used 3-4 lines of code from the package. So I copied those lines into our own class. Minimal maintenance will be required and we have eliminated usage of a popular package.
Code changes will need to be submitted with Unit Test that provides reasonable coverage of the new feature.