一定要注意

• 请确保你修改的类上的 JDoc, 有你的大名，比如 "@author zozoh(zozohtnt@gmail.com)"
  • 首先，体现了你的贡献
  • 否则，出了问题，不知道由谁主要负责
• 请尽量用统一的 code formatter， 导入 /nutz/doc/eclipse/nutz-eclipse-java-code-format-1.0.xml，否则我们同步代码是很难比较
• 去掉的代码不要注释掉，直接删掉。我们会用文件比较工具比较两个版本的不同

你需要知道

• Nutz 特点是代码短 （以不影响阅读为前提）
  • 无论任何时候，同样的功能，一段更短的代码，总比更长的代码要好
  • 这里的“短”，主要指的是“逻辑”短，而不是“字符长度”短
• 如果你指出，某一个函数或者类其实无用，是最大的贡献
• 删掉一段代码的贡献，比增加一段代码的贡献要大，至少不比它小
• 如果你有机会能将代码减少一行，既不影响阅读，也不影响效率，你的贡献很杰出
• 我希望代码越来越优美，我认为简单，直接，就是优美
• 实现什么样的功能，由社区决定
• 如何实现，由你决定
• 如果有可能，请尽量为 public 的类和方法写 Java Doc，中文或者英文都可以
• 主要的函数，需要由 JUnit 来保证质量
• 你必须遵守这样的编码原则: 请阅读 Nutz Java 编码规范

关于代码重写

• 接口的实现可以随时被重写，没关系，我们有版本控制，可以回滚
• 你的每一次提交，必须都是编译通过的
• 你的每一次提交，最好都是通过 JUnit 测试的
  • 除非有特别的情况 -- 比如你要和其他人分享的修改
• 我希望服务器上的代码通不过 JUnit 测试的情况，不要持续 3 天以上。最好，它时时刻刻都是可以通过全部 JUnit 测试的。

关于翻天覆地的重写

• 这是不可避免的
• 如果有充足的理由，我很高兴这样做
• 我很喜欢我现在写出的代码，但是我不能保证一直喜欢它们
• 实际上，我认为在相当长的一段时间里，我们没有精力维护两个或两个以上的版本，Nutz 应该只有 master

如果你不是，但是想成为代码提交者

• 你需要申请加入社区， 请至 https://nutz.cn/ 发帖
• 通过社区，你可以让我们了解你，如果你发的贴很有价值，我们会考虑邀请你成为代码提交者
• 或者你可以直接给任何一个 Nutz 的代码提交者发信， 指出 Nutz 代码哪里存在不足，并提供修改建议。
  • 如果连续五次，你的修改建议被接受，我们会邀请你成为 Nutz 的代码提交者 -- 当然你可以拒绝
• 除此之外，没有其他的途径