Move IntelliJ code style & copyright configuration to project-level settings #2652
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
August 10, 2021 13:24
## Motivation We currently expose IntelliJ code style & copyright configuration as standalone config files that users must manually import into their IDE. The import process is not too tedious, since the files are stored in Git (and thus readily available at the project level), but it requires users to know to find and import these files, and it's an unnecessary manual step for new users to be able to contribute. IntelliJ makes it easy to share configuration at the project-level. With its .idea directory structure, we can manually choose which files to share in Git. Then any user cloning the project will automatically use our recommended settings. ## Modifications * Copy intellij-codestyle.xml to project-level settings (and remove the old file) * Copy intellij-copyright-profile.xml to project-level settings (and remove the old file) * Update gitignore to not ignore the directories for these specific project-level settings * Update the GettingStarted guide accordingly ## Notes To generate the project-level code style, I used the existing intellij-codestyle.xml and performed the IntelliJ "copy to project" action. This resulted in some slight differences, like reordering of elements and elements like "GENERATE_FINAL_LOCALS" no longer being present, but from what I can tell this is due to them specifying the same as the default behavior. ## Resources https://stackoverflow.com/questions/9087439/how-to-share-code-style-settings-between-developers-in-intellij https://intellij-support.jetbrains.com/hc/en-us/articles/206544839 https://stackoverflow.com/questions/5533050/gitignore-exclude-folder-but-include-specific-subfolder
## Motivation We currently expose IntelliJ code style & copyright configuration as standalone config files that users must manually import into their IDE. The import process is not too tedious, since the files are stored in Git (and thus readily available at the project level), but it requires users to know to find and import these files, and it's an unnecessary manual step for new users to be able to contribute. IntelliJ makes it easy to share configuration at the project-level. With its .idea directory structure, we can manually choose which files to share in Git. Then any user cloning the project will automatically use our recommended settings. ## Modifications * Copy intellij-codestyle.xml to project-level settings (and remove the old file) * Copy intellij-copyright-profile.xml to project-level settings (and remove the old file) * Update gitignore to not ignore the directories for these specific project-level settings * Update the GettingStarted guide accordingly ## Notes To generate the project-level code style, I used the existing intellij-codestyle.xml and performed the IntelliJ "copy to project" action. This resulted in some slight differences, like reordering of elements and elements like "GENERATE_FINAL_LOCALS" no longer being present, but from what I can tell this is due to them specifying the same as the default behavior. ## Resources https://stackoverflow.com/questions/9087439/how-to-share-code-style-settings-between-developers-in-intellij https://intellij-support.jetbrains.com/hc/en-us/articles/206544839 https://stackoverflow.com/questions/5533050/gitignore-exclude-folder-but-include-specific-subfolder
millems
approved these changes
Aug 10, 2021
dagnir
approved these changes
Aug 10, 2021
## Motivation We currently expose IntelliJ code style & copyright configuration as standalone config files that users must manually import into their IDE. The import process is not too tedious, since the files are stored in Git (and thus readily available at the project level), but it requires users to know to find and import these files, and it's an unnecessary manual step for new users to be able to contribute. IntelliJ makes it easy to share configuration at the project-level. With its .idea directory structure, we can manually choose which files to share in Git. Then any user cloning the project will automatically use our recommended settings. ## Modifications * Copy intellij-codestyle.xml to project-level settings (and remove the old file) * Copy intellij-copyright-profile.xml to project-level settings (and remove the old file) * Update gitignore to not ignore the directories for these specific project-level settings * Update the GettingStarted guide accordingly ## Notes To generate the project-level code style, I used the existing intellij-codestyle.xml and performed the IntelliJ "copy to project" action. This resulted in some slight differences, like reordering of elements and elements like "GENERATE_FINAL_LOCALS" no longer being present, but from what I can tell this is due to them specifying the same as the default behavior. ## Resources https://stackoverflow.com/questions/9087439/how-to-share-code-style-settings-between-developers-in-intellij https://intellij-support.jetbrains.com/hc/en-us/articles/206544839 https://stackoverflow.com/questions/5533050/gitignore-exclude-folder-but-include-specific-subfolder
|
Removed copyright header from the config files themselves since it will be clobbered/overwritten whenever we change a setting preference, creating unnecessary churn (either in the diff or in having to manually preserve it). |
|
Kudos, SonarCloud Quality Gate passed! |
Bennett-Lynch
pushed a commit
to Bennett-Lynch/aws-sdk-java-v2
that referenced
this pull request
Aug 10, 2021
## Motivation Similar to how aws#2652 recently moved our code style & copyright configuration files to the project-level, we can also do the same for IntelliJ inspections. This has the benefit of keeping inspections in sync for all users, as well as automatically informing new users of our expected coding best practices. We do not currently have an existing inspection profile, so we will take this opportunity to start with a new, blank inspection profile. Users may then propose customizing the inspections via PRs, subject to the normal review process. Over time we will gravitate towards a shared inspection profile that we can all agree on. ## Modifications * Create a new, blank "AWS Java SDK 2.0" inspection profile * Update profiles_settings.xml to make users use this profile * Add corresponding gitignore update * Add corresponding GettingStarted update
1 task
Bennett-Lynch
pushed a commit
to Bennett-Lynch/aws-sdk-java-v2
that referenced
this pull request
Aug 10, 2021
## Motivation Similar to how aws#2652 recently moved our code style & copyright configuration files to the project-level, we can also do the same for IntelliJ inspections. This has the benefit of keeping inspections in sync for all users, as well as automatically informing new users of our expected coding best practices. We do not currently have an existing inspection profile, so we will take this opportunity to start with a new, blank inspection profile. Users may then propose customizing the inspections via PRs, subject to the normal review process. Over time we will gravitate towards a shared inspection profile that we can all agree on. ## Modifications * Create a new, blank "AWS Java SDK 2.0" inspection profile * Update profiles_settings.xml to make users use this profile * Add corresponding gitignore update * Add corresponding GettingStarted update
Bennett-Lynch
added a commit
that referenced
this pull request
Aug 10, 2021
* Create a shared, project-level IntelliJ inspection profile ## Motivation Similar to how #2652 recently moved our code style & copyright configuration files to the project-level, we can also do the same for IntelliJ inspections. This has the benefit of keeping inspections in sync for all users, as well as automatically informing new users of our expected coding best practices. We do not currently have an existing inspection profile, so we will take this opportunity to start with a new, blank inspection profile. Users may then propose customizing the inspections via PRs, subject to the normal review process. Over time we will gravitate towards a shared inspection profile that we can all agree on. ## Modifications * Create a new, blank "AWS Java SDK 2.0" inspection profile * Update profiles_settings.xml to make users use this profile * Add corresponding gitignore update * Add corresponding GettingStarted update
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
We currently expose IntelliJ code style & copyright configuration as
standalone config files that users must manually import into their IDE.
The import process is not too tedious, since the files are stored in
Git (and thus readily available at the project level), but it requires
users to know to find and import these files, and it's an unnecessary
manual step for new users to be able to contribute.
IntelliJ makes it easy to share configuration at the project-level. With
its .idea directory structure, we can manually choose which files to
share in Git. Then any user cloning the project will automatically use
our recommended settings.
Another benefit of this approach is that any changes to the existing
code style will be automatically shared and synced with users when
they pull the latest version.
Modifications
old file)
remove the old file)
project-level settings
Notes
To generate the project-level code style, I used the existing
intellij-codestyle.xml and performed the IntelliJ "copy to project"
action. This resulted in some slight differences, like reordering of
elements and elements like "GENERATE_FINAL_LOCALS" no longer being
present, but from what I can tell this is due to them specifying the
same as the default behavior.
Resources
https://stackoverflow.com/questions/9087439/how-to-share-code-style-settings-between-developers-in-intellij
https://intellij-support.jetbrains.com/hc/en-us/articles/206544839
https://stackoverflow.com/questions/5533050/gitignore-exclude-folder-but-include-specific-subfolder
License