Coding Guidelines for Bahmni

Bahmni Core Guidelines

Try and move all Data setup XMLs to bahmni-test-commons, avoid duplication of data setup XMLs at all costs. Also try to move all builders, or any code which might be relevant for other unit tests to the bahmni-test-commons module. 

Avoid redundancy of Hibernate mapping files, there is no need for that. If a Maven Module is a dependency then the application Context XML will be included in the parent module as well, so the mapping will be inherited. 

Take care of spring wiring, don't do a blind huge component scan on all the packages where some of them might not even include components, this increases the applications startup time. 

Avoid repetition of similar task in each and every test, since the Before annotation setup method runs before each and ever test, and if you need something run before class then use the BeforeClass annotation. 

Bahmni UI Coding Guidelines

• The mobile browsers (iPad and Android) do not support parsing ISO dates. Avoid using new Date(dateString) for parsing dates. Use DateUtil.parse() instead (which uses moment.js).
• In order to disable a "Submit" button, rely on checking the form's validity, rather than checking if a validation method passes. Make validation methods mark the input control as invalid, which indirectly will make form as invalid. That way the Submit button will get enabled only if the form is valid, which means all input controls on the form is valid. This will keep your submit method enabled/disable logic straightforward.

• Avoid using self-closing html tags for span, divs. The <span/> will be converted to <span> by grunt html validator and minifiers. The "dist" doesn't work as expected. Use <span></span> instead of <span/>. See http://stackoverflow.com/questions/3558119/are-self-closing-tags-valid-in-html5

• More angular guidelines related to performance boost is here.

General Guidelines for Code

1. Coding styles are important but not overbearing.
2. The code must not break any existing feature during upgrades
1. Data migrations if needed must be done so as to persist and keep working with existing transactional data.
2. Configuration if introduced must have the previous behavior as the default, with options of extending/changing the behavior. Meaning, using existing configuration with new code does not require updates by any implementation. Configurations are documented and reflected with the release version indicated.
3. Feature behaves, as much as possible, like before and is easy to pick up and preferably does not require retraining of end users.
3. Unused code
   1. Don’t carry dead code, including commented off code is not useful and just baggage and often confusing. We use git anyways and all editors show a pretty good diff between versions!
   2. Duplicate code - maybe create another card?
4. Encourage using Java 8 paradigms
1. Use of closeable in try-with-resources
2. Using streams
3. Loops like “names.forEach”
4. Lambda expressions
5. DRY - don’t repeat yourself please.
6. Loops have definite set length and correct termination conditions.
7. Is the code performant? Has it been tested with enough representative data? (Ask the contributor to share what they've done, or test it yourself if you have concerns.)
8. ROT code? - surely someone has come up against it? Use a known library if you can’t find already plugged in.  
9. SOLID principle

References

There are enough guidelines available on internet to help you. 

Java

1. https://www.javacodegeeks.com/2015/06/java-programming-tips-best-practices-beginners.html
2. https://medium.com/@rhamedy/a-short-summary-of-java-coding-best-practices-31283d0167d3
3. Oracle technet (now archived) - https://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html
4. https://docs.oracle.com/cd/A97688_16/generic.903/bp/java.htm

React 

1. https://reactjs.org/docs/thinking-in-react.html

Angular

1. TODO

Python 

1. https://airbrake.io/blog/python/python-best-practices