diff --git a/doc/dev/decisionrecords/Codestyle.md b/doc/dev/decisionrecords/Codestyle.md index 72db4796291..170c592f437 100644 --- a/doc/dev/decisionrecords/Codestyle.md +++ b/doc/dev/decisionrecords/Codestyle.md @@ -53,7 +53,7 @@ But, if you have set a custom code style in your settings (as we used until OTP to change to the _Project_ code style. Open the `Preferences` from the menu and select _Editor > Code Style_. Then select **Project** in the \_Scheme drop down. -#### Run Prettier Maven Plugin as an external tool in IntelliJ +#### Run Prettier Maven Plugin as an External Tool in IntelliJ You can run the Prettier Maven plugin as an external tool in IntelliJ. Set it up as an `External tool` and assign a keyboard shortcut to the tool execution. @@ -70,7 +70,7 @@ Working Directory: $ProjectFileDir$ > **Tip!** Add an unused key shortcut to execute the external tool. Then you can use the old > shortcut to format other file types. -#### Install File Watchers plugin in IntelliJ +#### Install File Watchers Plugin in IntelliJ You can also configure IntelliJ to run Prettier every time IntelliJ saves a Java file. But if you are editing the file at the same time, you will get a warning that the file in memory and the file @@ -106,9 +106,8 @@ feel free to share it. Some of the classes in OTP have a lot of fields and methods. Keeping members sorted reduces merge conflicts. Adding fields and methods to the end of the list will cause merge conflicts more often -than will inserting methods and fields in an ordered list. Fields and methods can be sorted in -"feature" sections or alphabetically, but stick to it and respect it when adding new methods and -fields. +than inserting methods and fields in an ordered list. Fields and methods can be sorted in "feature" +sections or alphabetically, but stick to it and respect it when adding new methods and fields. The provided formatter will group class members in this order: @@ -166,7 +165,7 @@ context. Please avoid including trivial Javadoc or the empty Javadoc stubs added - On fields: - Fields should be marked as `@Nullable` if they are nullable. -Use of `@NonNull` annotation is not allowed. It should be assumed methods/parameters/fields are +Use of `@Nonnull` annotation is not allowed. It should be assumed methods/parameters/fields are non-null if they are not marked as `@Nullable`. However, there are places where the `@Nullable` annotation is missing even if it should have been used. Those can be updated to use the `@Nullable` annotation. diff --git a/doc/dev/decisionrecords/NamingConventions.md b/doc/dev/decisionrecords/NamingConventions.md index 0c7cd201d7d..53c783950d9 100644 --- a/doc/dev/decisionrecords/NamingConventions.md +++ b/doc/dev/decisionrecords/NamingConventions.md @@ -63,7 +63,7 @@ them. Naming convention for builders with and without a context. -#### Graph builds and tests run without a context +#### Graph Builds and Tests Run Without a Context ```java // Create a new Stop diff --git a/doc/dev/decisionrecords/RecordsPOJOsBuilders.md b/doc/dev/decisionrecords/RecordsPOJOsBuilders.md index 3112760cbe7..d34fd3ab6b7 100644 --- a/doc/dev/decisionrecords/RecordsPOJOsBuilders.md +++ b/doc/dev/decisionrecords/RecordsPOJOsBuilders.md @@ -27,7 +27,7 @@ types of these fields. OTP used a simple builder pattern in many places, especially when creating immutable types. -#### Builder conventions +#### Builder Conventions - Use factory methods to create builder—either `of` or `copyOf`. The `copyOf` uses an existing instance as its base. The `of` creates a builder with all default values set. All constructors @@ -47,7 +47,7 @@ OTP used a simple builder pattern in many places, especially when creating immut - For nested builders, see the field `nested` in the example.
- Builder example + Builder Example ```java /** diff --git a/doc/dev/decisionrecords/UseDecisionRecords.md b/doc/dev/decisionrecords/UseDecisionRecords.md index 0c07f89fd12..9635c36fe88 100644 --- a/doc/dev/decisionrecords/UseDecisionRecords.md +++ b/doc/dev/decisionrecords/UseDecisionRecords.md @@ -15,7 +15,7 @@ a bit more discussion and explanation, then we will create a PR with a document Use the [template](/doc/dev/decisionrecords/_TEMPLATE.md) as a starting point for documenting the decision. -### How to discuss and document a Decision Record +### How to Discuss and Document a Decision Record - Create a new pull request and describe the decision record by adding a document to the `/doc/dev/decisionrecords` folder. Use the [template](/doc/dev/decisionrecords/_TEMPLATE.md).