我们努力保持 SciJava 代码库清晰、一致且易于阅读，其中包括源代码和修订的历史记录。
接口驱动设计
SciJava 项目职责使用 interface-driven design。公共接口、枚举和常量（即 public static final 字段）构成了 SciJava 与下游代码的 API 契约的基础。虽然我们努力不改变非接口的公共方法和字段，但它们有时可能需要进行更改以改进系统。
版本控制
SciJava 项目使用Semantic Versioning。截至撰写正文时，该项目仍处于测试阶段，因此 API 尚未最终确定。但一旦我们发布最终的 2.0.0 版本，未来的版本将完全兼容。有关更多信息，详细信息请参阅Architecture页面。
命名
我们尝试用与Java标准库类似的逻辑来命名类。我们避免使用接口的“I”导出，以及实现的“Impl”后缀。相反，像Java标准库一样，我们为抽象超类添加“Abstract”远端，为规范实现添加“Default”远端，例如，Display接口由名为AbstractDisplay的抽象超类实现，并由名为DefaultDisplay的具体实现扩展。
聪明
由于大量开发人员研究 SciJava 代码库，并且它提供了许多使用示例，因此，我们尝试提供easy to understand, maintainable code。我们避免使用“聪明”或混乱的问题解决方案，因为这样的代码往往更难以理解。
单片机历史
我们尝试遵循最佳实践来维护干净且有组织的 Git 历史记录：
- 我们提供一个持久、稳定的主分支（即无强制主动）。
- 我们编写了thorough, informative和well-formatted提交消息。根据经验：无法从补丁本身轻松推断出的相关信息应在提交消息的body中提供，例如首先尝试了哪些其他方法以及为什么它们失败，为什么需要尝试的启发性简介，或者讨论的链接。
- 总的来说，我们更喜欢合并而不是变基，以便个人提交继续反映实际的真实开发历史（即当时经过测试和工作的内容）。其次，我们有时确实在主题分支上使用变基，以保持我们的提交组织良好且易于理解。
- 我们使用主题分支来添加大量功能和复杂的代码更改，并在合并到主分支后立即清除它们。我们更喜欢进行显式合并（即使用
--no-ff）来记录每个合并分支的用途。 - 为了细化主题分支的提交，我们广泛使用
git commit --fixup <commit>。另外的git rebase --autosquash将修复压缩到另一个提交中。 - 如果完成编码会话结束时有未完成的工作，我们将其与主题 WIP 一起工作主动并到主题分支。（接下来调用
git reset HEAD^可以轻松地从那里继续工作。）这样可以减少工作的机会，可以澄清其他程序员在开发过程中更容易进行协作。 - 我们避免怪物提交（使用诸如“对多个子系统进行许多更改”之类的提交消息），而有利于一次概念更改的良好分离的敏捷提交。Git 的暂存区域功能使这变得更加容易（例如，
git add -p）。粒度提交有很多优点；例如，§§§CODE1§§§ bisect`对于理解神秘的错误变得更加有用。
Javadoc 和注释
我们尝试在添加代码时编写Javadoc，而不是指定为稍后添加。我们的目的是为所有公共类型提供Javadoc。至少，我们为任何待处理的Javadoc添加TODO注释。我们的目标是让所有Javadoc正确呈现为HTML（即在Web浏览器中），是在源代码中修补空白格式。
我们还有一些在各种情况下使用的评论标记：
- 如果代码可能无法理解或令人惊讶，我们会添加 “HACK” 注释来提供解释。
- 对于被认为“肮脏”或不太理想但从实际角度来看是必要的代码，我们添加一条 “NB” 注释对此进行解释。
- 对于被认为有错误或损坏且需要修复的代码（或缺少代码），我们添加标有相关开发人员姓名首字母的“FIXME”注释，以提醒您在时间允许的情况下尽快解决该问题。
- 当某处需要额外的工作但不紧急时，我们添加一个“TODO”注释来标记它。
- 为了简化删除的临时代码，我们用“TEMP”标记对其进行标记。
Eclipse 代码风格配置文件
我们提供Eclipse configuration files in the source repository来定义代码结构和格式的规则。 注意从存储库下载.epf文件时，不要单击链接另存为…，而是创建文件my-file-name.epf，然后复制粘贴该文件的内容。因此，请单击eclipse-preferences.epf，然后点击 Raw 按钮。
您可以使用 Java › Code Style › Clean Up 并 eclipse-preferences.epf 文件将它们导入到您的系统中。然后，在 Eclipse 首选项中，导航至 File › Import › Preferences 并选择“ImageJ”作为配置活动文件。然后，您可以通过右键点击源文件并上下文菜单中选择Source › Clean Up来格式化源代码。完成论文时，CI尚未自动应用这些规则，但我们有时会努力手动将它们应用到代码库中。
代码块的排序
为了保持一致性，我们更喜欢类中代码块的以下顺序：
- 公共常量（即
public static final）。 2.非公共常量。 3.静态字段。 4.静态初始化程序（如果需要）。 5.实例字段。 6.构造函数。 7.特定类的公共方法。 - 类的超类的公共方法重写。
- 类的已实现接口的公共方法实现，其顺序与它们在接口中出现的顺序相同。
- 公共静态方法（标记为“–实用方法–”）。 11.受保护的事件处理程序方法（标记为“–事件处理程序–”）。 12.任何其他受保护的方法（标记为“–内部方法–”）。
- 方法（标记为“–辅助方法–”）。
- 已弃用的方法（标记为“–已弃用的方法–”）。
- 内部类型（标记为“– Helper 类 –”）。
我们还尝试单独标记每个代码段；即，每个类和接口的方法都被单独标记和分组。
尽管现代 IDE 提供了许多功能来获取方法和变量的源，但我们仍然相信这种顺序可以更轻松地在代码中找到您要查找的内容。
受保护的字段和方法接头
在可能的情况下，我们更喜欢使用非封闭字段和方法是不受保护的字段和方法。虽然非封闭字段对于要子类化的类来说是一种方便的构造，但使用它们有几个缺点：
- 受保护的字段为子类提供API契约，尤其是对于可重用库，必须仔细这一点，就像公共API一样。由于受保护的字段太多，你可能会发现自己被锁定在当前的内部设计中，重构变得困难或不可能。
- 您不能对受保护区域的使用进行任何或控制。相反，为断开字段提供 getter 和 setter 可以在代码中定义对这些字段所需的任何限制。
- 与此相关的是，Java中没有任何机制，即使使用Javassist等字节码库，也无法添加在读取或写入字段时注入或修改行为的“接缝”。例如，您以后无法关心该字段的值何时更改侦听器添加通知系统。事实上，根本无法检测到字段发生变化时，例如以下目的：同步。在ImageJ2的我们在您的层到ImageJ时遇到这个特定问题，因为它有几乎很多的非屏蔽字段：当未知的第三方更改存储ImageJ程序状态部分的ImageJ 字段时，我们无法更新相应的 ImageJ2 状态以匹配。对于这个困境，我们基本上仍然没有解决方案（另外，我们想找出最好的方法是轮询，这很复杂而且很容易出错）。
4.非封装字段的一种很好的用法是用于“struct”类型的类，例如
java.awt.Rectangle，具有x、y、width和height字段。如果你正在寻找的只是一个由基元和对象引用集合组成的“哑”数据结构类，那么它就足够了，但有了上述几点，几乎总是使用带有getter和setter的方法的空白字段，即使在完全打算子类化的类中也是如此。
有关此问题的更多意见可以在this post on StackOverflow中找到。
综上所述，有时使用 protected 修饰符是合适的，你肯定会在 SciJava 代码库中的几个地方看到它。特别是，我们对事件处理程序方法使用protected，既可以避免 Eclipse 中出现未使用的方法警告，也可以使子类更容易覆盖事件处理行为。
