IntelliJ Platform Coding Guidelines

如果您要编写想要为IntelliJ平台贡献的代码(作为补丁或插件),遵循这些指导原则将使JetBrains开发团队更容易查看和接受您的更改.

遵循最新源代码

如果您提交补丁,我们强烈建议您根据Git存储库中的最新版本的代码构建补丁. 最简单的方法是克隆JetBrains Git存储库,在Git中跟踪您的工作,并使用“git format-patch”命令创建补丁.

一般建筑原理

请尽力遵循常见的Java架构原则. 约书亚布洛赫的“有效Java”是一个很好的起点.

测试

IntelliJ IDEA的大多数现有功能都包含在功能测试中. 如果要修改的区域由测试覆盖,则必须运行测试并确保更改不会引入任何新的测试失败. 还强烈建议您提供新的功能测试,以涵盖您修复的错误或您添加的新功能.

代码格式

我们对代码格式化一般都很松懈,但至少必须遵守以下约定:

• 源文件中有2个空格缩进

• 实例变量的前缀和类变量的我们的前缀

• 新的源代码文件必须包含带有Apache 2许可证和贡献者名称的版权声明.

遵循我们的代码格式化指南的最简单方法是使用共享代码样式重新格式化代码提交,该代码样式包含在IntelliJ IDEA Community Edition项目目录中.

检查

IntelliJ IDEA Community Edition项目包括共享检查配置文件. 我们强烈建议您确保所提交的代码不包含该检查配置文件中配置的检查突出显示的任何警告.

JavaDoc评论

如果您的代码添加了新的OpenAPI接口,类,方法或扩展点,则必须提供描述API的参数和预期用法的JavaDoc注释. 为代码的其他部分提供JavaDoc或其他注释是个好主意,但不是必需的.

承诺

在查看更改时,为避免不必要的工作,请遵循以下准则:

• 在提交给我们之前,查看补丁或拉取请求中的所有更改. 确保你改变的一切都是有原因的.

• 请不要在补丁中包含未完成的工作. 确保它不包含任何TODO注释. 如果您添加了一些代码但最终不需要它,请确保在提交补丁之前将其删除.

• 请不要包含任何影响格式的更改,修复“黄色代码”(警告)或代码样式以及修复错误或实现功能的实际更改. 没有人愿意留下糟糕的代码,但请记住,将这些变化相互混合会使审查过程变得复杂.

• 请不要在单个补丁或拉取请求中修复多个问题.

• 请不要对配置文件(runConfigurations/IDEA.xml,codeStyleSettings.xml,misc.xml等)进行个人更改,除非它对修复本身至关重要.

• 除非有必要修复,否则请避免移动或重命名课程.

理想的pull请求将包含1个提交,其中包含修复bug或实现某个功能所需的所有内容,但没有其他内容. “提前提交,经常提交”完全适用于本地提交,但这种“公共提交”很难审核(审核人员需要花费更多时间来审核正在进行的工作或审核所有更改 立即丢失存储在提交消息中的有价值信息).

最好的方法是尽早提交,然后将所有提交压缩成一个带有描述性提交消息的提交.

有时单个问题的几个提交也是可以接受的,但是每个提交都需要是自包含的“步骤”来解决问题.