Code Style

Configure Java Style for IntelliJ

First, download the style configuration.

curl https://raw.githubusercontent.com/google/styleguide/gh-pages/intellij-java-google-style.xml -o ~/Downloads/intellij-java-google-style.xml

Install it in IntelliJ:

1. Go to Preferences > Editor > Code Style
2. Press the little cog:
   1. Import Scheme > IntelliJ IDEA code style XML
   2. Select the file we just downloaded
3. Select GoogleStyle in the dropdown
4. Change default Hard wrap at in Wrapping and Braces tab to 150
5. Use explicit imports
   1. Under Preferences > Code Style > Java > Imports
      1. change Class count to use import with '*' to 9999
      2. change Names count to use static import with '*' to 9999
   2. Under Preferences > Code Style > Kotlin > Imports
      1. change Top Level Symbols to Use single name import
      2. change Java Statics and Enum Members to Use single name import
6. Add the final keyword wherever possible. You can either set this as the default for your IDE or you can set it just for the Airbyte project(s) that you are using
   1. Turn on the inspection. Go into Preferences > Editor > Inspections
      1. Search "Field may be 'final'" > check the box
      2. Search "local variable or parameter can be 'final'" > check the box
      3. Apply the changes
   2. Turn on the auto add final. Go into IntelliJ Preferences
      1. Plugins - install Save Actions if not already installed
         1. If you're running Intellij 2023.1 or higher, the official version may not work. Try manually installing this fork (see Github issue).
      2. Go to Save Actions in the preferences left navigation column (NOT Tools > Actions on Save -- that is a different tool)
         1. Activate save actions on save > check the box
         2. Active save actions on shortcut > check the box
         3. Activate save actions on batch > check the box
         4. Add final modifier to field > check the box
         5. Add final modifier to local variable or parameter > check the box
         6. Apply the changes
7. You're done!

Source code comments

It's hard to pin down exactly what to do around source code comments, but there are two (very subjective) and rough guidelines:

If something is not obvious, write it down. Examples include:

• non-trivial class definitions should have docstrings
• magic variables should have comments explaining why those values are used (e.g: if using a page size of 10 in a connector, describe why if possible. If there is no reason, that's also fine, just mention in a comment).
• Complicated subroutines/logic which cannot be refactored should have comments explaining what they are doing and why

If something is obvious, don't write it down since it's probably more likely to go out of date. For example, a comment like x = 42; // sets x to 42 is not adding any new information and is therefore better omitted.