The JHipster development team follows some coding policies. You can see them as “best practices” or “guidelines”. They are enforced on the project itself, not on the generated code: if you use JHipster to generate your project, you absolutely do not have to follow them!
Those policies are followed by the development team, and you should follow them if you submit a Pull Request.
Policy 0: Policies are voted by the development team
Each policy can be discussed or modified by the development team on the mailing list. Any significant change must be voted (+1 if you agree, -1 if you disagree).
Policy 1: technologies used by JHipster have their default configuration used as much as possible
For example, we use JPA, Spring, Angular and React the “usual way”, without some heavy configuration options and with their usual naming and coding conventions. We do this as:
- Each technology usually has a very good reason to have those defaults
- It’s much easier to understand how JHipster works if we don’t re-configure everything
We might only change a default configuration if it produces some issue with the other technologies used by JHipster. For example, to have Spring Security and Angular working together, we had to change Spring Security’s default configuration.
Policy 2: only add options when there is sufficient added-value in the generated code
JHipster has many options when generating a project. We only add those options when they are complex and imply configuring or coding several components.
Adding an option only because it saves a couple of lines to code isn’t a good usage of JHipster:
- It’s easier to code those lines manually than to learn a new JHipster option
- It will only make our generator more complex without adding any value
Policy 3: for the Java code, follow the default Intellij IDEA coding style
There are many ways to format your code. We follow the default rules provided by Intellij IDEA.
Policy 4: use strict versions for third-party libraries