-
Notifications
You must be signed in to change notification settings - Fork 35
4.2. Guidelines
Developers interested in contributing to the LWJGL codebase, should be aware of the following guidelines:
Every Java source file in the LWJGL codebase is formatted using a strict code style. The particulars of this code style are not important and are not set in stone. What is important is consistency; any new code committed to LWJGL is required to follow the exact same code style. If that style ever changes, it is also required that all current source files be reformatted with the new styling rules.
This is of course a bit too strict to require for pull requests. LWJGL maintainers will accept pull requests with incompatible formatting, but are required to reformat the code before merging it into the repository.
For convenience, the IntelliJ IDEA project, found at the .idea directory, comes with code style settings that match the LWJGL code style. Equivalent settings for Eclipse will also be provided in the future.
- Tab size: 4 spaces
- Right margin (wrap): 160 columns/chars
Contributors should try to follow these code conventions:
- Never use final for local variables and parameters. These are unnecessarily verbose and you can configure modern IDEs to treat method parameters as final.
- Always add an @Override annotation on methods that override or implement a supertype method.
- Always use static imports for LWJGL bindings (GL, CL, etc) and also prefixed methods in utility classes (e.g.
MemoryUtil).
Native code is compiled with the most strict warnings enabled on all compilers. Warnings are also treated as errors and any warning will interrupt compilation. This is a minor inconvenience, but it's crucial to LWJGL's cross-platform nature. Unless we encounter a major issue, these warnings will stay enabled and contributors are required to fix any incompatibilities in their code.
LWJGL also provides two macros, DISABLE_WARNINGS() and ENABLE_WARNINGS(), that can be used to wrap code that is causing trouble. They should only be used in or around #include statements to 3rd-party headers and not for cheating the compiler.