Contributing

Coding Conventions

HAPI FHIR uses the jakarta.annotation.Nullable and jakarta.annotation.Nonnull annotations (where relevant and useful), as opposed to the equivalent org.jetbrains annotations. See this StackOverflow for a description on how to set this in IntelliJ.

Code Style

The HAPI FHIR codebase uses the following code style conventions. We are not strict about these, but consistency is a good thing so please consider using them.

Variable naming:

• Parameters are named theFoo
• Fields are named myFoo
• Statics are named ourFoo
• Constants are named FOO_CONSTANT

Code Formatting

HAPI-FHIR uses the maven spotless plugin. Code is formatted with palantir java format as our repository format, due to its line length of 120, along with its focus on formatting code specifically to be easier to code review.

Only production code is auto-linted, test code is omitted currently, due to certain whitespace requirements for test asserts. Eventually this will be rectified.

Code is automatically formatted any time you either run:

• mvn clean install -DskipTests
• mvn spotless:apply

You can also make use of the pre-commit project to add an optional pre-push hook. This can be setup by installing pre-commit as indicated on their website, and then running pre-commit install --hook-type pre-push. After that, any time you attempt a push, spotless will apply all formatting changes automatically on push. Note that while the installation of this pre-push hook is optional for developers, the pipeline will fail if formatting has not been done.

If your code is not formatted by the time it hits the pipeline, the new github action will fail.

The project also uses an .editorconfig file to avoid ever worrying about tabs vs. spaces issues. There are plugins for most IDEs (and IntelliJ has built in support) for this format, so it is highly recommended to use it.

Test naming

• Test classes end with Test (e.g. SubscriptionCanonicalizerTest) or IT (e.g. Batch2CoordinatorIT)
• Test classes named *Test should be safe to run in parallel.
• Any test that depends on external resources (e.g. Docker containers) or is otherwise unsafe to run in parallel should be named *IT. These will be run as integration tests, one at a time, in isolated jvms.
• We are experimenting with a naming scheme for microtests (quick, narrow, unit-tests): test methods are named by template methodName_StateUnderTest_ExpectedBehavior. See the first convention in this list.