community/cn/involved/conduct/index.xml - shardingsphere-doc - Git at Google

 <?xml version="1.0" encoding="utf-8" standalone="yes"?>
 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
   <channel>
     <title>贡献规约 on ShardingSphere</title>
     <link>https://shardingsphere.apache.org/community/cn/involved/conduct/</link>
     <description>Recent content in 贡献规约 on ShardingSphere</description>
     <generator>Hugo -- gohugo.io</generator>
     <language>en-us</language><atom:link href="https://shardingsphere.apache.org/community/cn/involved/conduct/index.xml" rel="self" type="application/rss+xml" />
     <item>
       <title>Issue 提交与处理规范</title>
       <link>https://shardingsphere.apache.org/community/cn/involved/conduct/issue/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>

       <guid>https://shardingsphere.apache.org/community/cn/involved/conduct/issue/</guid>
       <description>Issue 提交规范  Issue 列表以可读和可检索为目标，提交者有义务将标题总结的有意义和易于检索，并保持内容的正确和完整性； 请在经过充分的检索之后，确定无相关的已存在 Issue，再提交新的 Issue； Issue 类型划分为缺陷报告、新功能请求和问题，请在提交 Issue 时选择正确的模板并根据模板填写其内容； 由配置不确定等产生的问题，请将相关的可重现代码提交至 GitHub，以便于社区贡献者定位和确定问题； 请在 Issue 得到解决之后，回复该 Issue，形成闭环，为其他浏览此 Issue 的读者提供有效信息； 请及时关注已提交的 Issue，长时间无反馈的 Issue 将定期关闭； 为保证社区多元化，请使用英文参与交流。  Issue 处理规范  对于标题不明晰的 Issue，由处理人引导提交者将标题修改完善后再行处理； 对于内容缺失模板必要信息的 Issue，由处理人引导提交者将所需信息提供完善后再行处理； 涉及到缺陷修复、功能提升等与代码相关的 Issue，都将标记正确的标签以及完成此 Issue 的项目版本； 处理人将定期关闭长时间无反馈的 Issue； 无参考和检索价值的 Issue 将被标记为 status:invalid，读者无需关注。  </description>
     </item>

     <item>
       <title>开发规范</title>
       <link>https://shardingsphere.apache.org/community/cn/involved/conduct/code/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>

       <guid>https://shardingsphere.apache.org/community/cn/involved/conduct/code/</guid>
       <description>以下行为准则以完全遵循 Apache 软件基金会行为准则为前提。
 开发理念  用心 保持责任心和敬畏心，以工匠精神持续雕琢。 可读 代码无歧义，通过阅读而非调试手段浮现代码意图。 整洁 认同《重构》和《代码整洁之道》的理念，追求整洁优雅代码。 一致 代码风格、命名以及使用方式保持完全一致。 精简 极简代码，以最少的代码表达最正确的意思。高度复用，无重复代码和配置。及时删除无用代码。 抽象 层次划分清晰，概念提炼合理。保持方法、类、包以及模块处于同一抽象层级。 极致 拒绝随意，保证任何一行代码、任何一个字母、任何一个空格都有其存在价值。  代码提交行为规范  确保遵守编码规范。 确保构建流程中的各个步骤都成功完成，包括：Apache 协议文件头检查、Checkstyle 检查、编译、单元测试等。构建流程启动命令：./mvnw clean install -B -T1C -Pcheck。 通过 Spotless 统一代码风格，执行 ./mvnw spotless:apply -Pcheck 格式化代码。 确保覆盖率不低于 master 分支。 应尽量将设计精细化拆分；做到小幅度修改，多次数提交，但应保证提交的完整性。 如果您使用 IDEA，可导入推荐的 src/resources/code-style-idea.xml。  编码规范  使用 linux 换行符。 不应有无意义的空行。请提炼私有方法，代替方法体过长或代码段逻辑闭环而采用的空行间隔。 命名规范：  命名要做到顾名思义。 类、方法名避免使用缩写，部分变量名可以使用缩写。  变量名 arguments 缩写为 args； 变量名 parameters 缩写为 params； 变量名 environment 缩写为 env； 变量名 properties 缩写为 props； 变量名 configuration 缩写为 config。   三位以内字符的专有名词缩写使用大写，超过三位字符的缩写采用驼峰形式。  三位以内字符的类和方法名称缩写的示例：SQL92Lexer、XMLTransfer、MySQLAdminExecutorCreator； 三位以上字符的类和方法名称缩写的示例：JdbcUrlAppender、YamlAgentConfigurationSwapper； 变量应使用小驼峰形式：mysqlAuthenticationMethod、sqlStatement、mysqlConfig。   符合下列条件的局部变量，应参照下列规则命名：  除了直接返回方法入参，返回变量使用 result 命名； 循环中使用 each 命名循环变量； map 中使用 entry 代替 each； 捕获的异常名称命名为 ex ； 捕获异常且不做任何事情，异常名称命名为 ignored。   方法入参名禁止使用 result、each、entry。 工具类名称命名为 xxUtils。 配置文件使用 Spinal Case 命名（一种使用 - 分割单词的特殊 Snake Case）。   需要注释解释的代码尽量提成小方法，用方法名称解释。 equals 和 == 条件表达式中，常量在左，变量在右；大于小于等条件表达式中，变量在左，常量在右。 除了构造器入参与全局变量名称相同的赋值语句外，避免使用 this 修饰符。 局部变量不应设置为 final。 除了用于继承的抽象类之外，尽量将类设计为 final。 嵌套循环尽量提成方法。 成员变量定义顺序以及参数传递顺序在各个类和方法中保持一致。 优先使用卫语句。 类和方法的访问权限控制为最小。 方法所用到的私有方法应紧跟该方法，如果有多个私有方法，书写私有方法应与私有方法在原方法的出现顺序相同。 方法入参和返回值不允许为 null。 优先使用 lombok 代替构造器，getter, setter 方法和 log 变量。 优先考虑使用 LinkedList，只有在需要通过下标获取集合中元素值时再使用 ArrayList。 ArrayList，HashMap 等可能产生扩容的集合类型必须指定集合初始大小，避免扩容。 优先使用三目运算符代替 if else 的返回和赋值语句。 禁止嵌套使用三目运算符。 条件表达式中，优先使用正向语义，以便于理解代码逻辑。例如：if (null == param) {} else {}。 使用具体的 @SuppressWarnings(&amp;quot;xxx&amp;quot;) 代替 @SuppressWarnings(&amp;quot;all&amp;quot;)。 合理使用 @HighFrequencyInvocation 注解，用于聚焦关键方法性能的优化。  使用 @HighFrequencyInvocation 注解的时机：  请求频繁调用的链路，标注其中高频调用的类、方法或构造器，标注范围精确匹配； canBeCached 属性为 true 时，表示该目标为可复用的缓存资源，例如：数据库连接。   标注 @HighFrequencyInvocation 的代码段须严格保证代码性能，以下为标注代码段内的禁止项：  禁止调用 Java Stream API； 禁止通过 + 拼接字符串； 禁止调用 LinkedList 的 get(int index) 方法。     注释 &amp;amp; 日志规范：  日志与注释一律使用英文。 注释只能包含 javadoc，todo 和 fixme。 公开的类和方法必须有 javadoc，对用户的 API 和 SPI 的 javadoc 需要写的清晰全面，其他类和方法以及覆盖自父类的方法无需 javadoc。    单元测试规范  测试代码和生产代码需遵守相同代码规范。 单元测试需遵循 AIR（Automatic, Independent, Repeatable）设计理念。  自动化（Automatic）：单元测试应全自动执行，而非交互式。禁止人工检查输出结果，不允许使用 System.</description>
     </item>

     <item>
       <title>文档规范</title>
       <link>https://shardingsphere.apache.org/community/cn/involved/conduct/document/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>

       <guid>https://shardingsphere.apache.org/community/cn/involved/conduct/document/</guid>
       <description> 文档标题仅在 title = &amp;quot;xxx&amp;quot; 中出现， 文档内部无需主标题（#）； 每篇文档结尾留一空行； 为避免段落过长，请在句号结尾处换行； 标题和内容需要保留空行； 为方便阅读，除了最后一列，表格的每列需要严格对齐； 表格表头的 | 与 - 之间需要保留一个空格； 数字标记的段落均使用 1. ，由 Hugo 自动生成序号； 列表项使用；结尾，最后一项用。结尾； 请勿在英文文档中使用中文字符； 中英文之间需要空格； 图片文件结尾使用语言缩写以区分图片中的不同语言，如：_cn 和 _en。  </description>
     </item>

   </channel>
 </rss>
	<?xml version="1.0" encoding="utf-8" standalone="yes"?>
	<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
	<title>贡献规约 on ShardingSphere</title>
	<link>https://shardingsphere.apache.org/community/cn/involved/conduct/</link>
	<description>Recent content in 贡献规约 on ShardingSphere</description>
	<generator>Hugo -- gohugo.io</generator>
	<language>en-us</language><atom:link href="https://shardingsphere.apache.org/community/cn/involved/conduct/index.xml" rel="self" type="application/rss+xml" />
	<item>
	<title>Issue 提交与处理规范</title>
	<link>https://shardingsphere.apache.org/community/cn/involved/conduct/issue/</link>
	<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>

	<guid>https://shardingsphere.apache.org/community/cn/involved/conduct/issue/</guid>
	<description>Issue 提交规范 Issue 列表以可读和可检索为目标，提交者有义务将标题总结的有意义和易于检索，并保持内容的正确和完整性；请在经过充分的检索之后，确定无相关的已存在 Issue，再提交新的 Issue； Issue 类型划分为缺陷报告、新功能请求和问题，请在提交 Issue 时选择正确的模板并根据模板填写其内容；由配置不确定等产生的问题，请将相关的可重现代码提交至 GitHub，以便于社区贡献者定位和确定问题；请在 Issue 得到解决之后，回复该 Issue，形成闭环，为其他浏览此 Issue 的读者提供有效信息；请及时关注已提交的 Issue，长时间无反馈的 Issue 将定期关闭；为保证社区多元化，请使用英文参与交流。 Issue 处理规范对于标题不明晰的 Issue，由处理人引导提交者将标题修改完善后再行处理；对于内容缺失模板必要信息的 Issue，由处理人引导提交者将所需信息提供完善后再行处理；涉及到缺陷修复、功能提升等与代码相关的 Issue，都将标记正确的标签以及完成此 Issue 的项目版本；处理人将定期关闭长时间无反馈的 Issue；无参考和检索价值的 Issue 将被标记为 status:invalid，读者无需关注。 </description>
	</item>

	<item>
	<title>开发规范</title>
	<link>https://shardingsphere.apache.org/community/cn/involved/conduct/code/</link>
	<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>

	<guid>https://shardingsphere.apache.org/community/cn/involved/conduct/code/</guid>
	<description>以下行为准则以完全遵循 Apache 软件基金会行为准则为前提。
	开发理念用心保持责任心和敬畏心，以工匠精神持续雕琢。可读代码无歧义，通过阅读而非调试手段浮现代码意图。整洁认同《重构》和《代码整洁之道》的理念，追求整洁优雅代码。一致代码风格、命名以及使用方式保持完全一致。精简极简代码，以最少的代码表达最正确的意思。高度复用，无重复代码和配置。及时删除无用代码。抽象层次划分清晰，概念提炼合理。保持方法、类、包以及模块处于同一抽象层级。极致拒绝随意，保证任何一行代码、任何一个字母、任何一个空格都有其存在价值。代码提交行为规范确保遵守编码规范。确保构建流程中的各个步骤都成功完成，包括：Apache 协议文件头检查、Checkstyle 检查、编译、单元测试等。构建流程启动命令：./mvnw clean install -B -T1C -Pcheck。通过 Spotless 统一代码风格，执行 ./mvnw spotless:apply -Pcheck 格式化代码。确保覆盖率不低于 master 分支。应尽量将设计精细化拆分；做到小幅度修改，多次数提交，但应保证提交的完整性。如果您使用 IDEA，可导入推荐的 src/resources/code-style-idea.xml。编码规范使用 linux 换行符。不应有无意义的空行。请提炼私有方法，代替方法体过长或代码段逻辑闭环而采用的空行间隔。命名规范：命名要做到顾名思义。类、方法名避免使用缩写，部分变量名可以使用缩写。变量名 arguments 缩写为 args；变量名 parameters 缩写为 params；变量名 environment 缩写为 env；变量名 properties 缩写为 props；变量名 configuration 缩写为 config。三位以内字符的专有名词缩写使用大写，超过三位字符的缩写采用驼峰形式。三位以内字符的类和方法名称缩写的示例：SQL92Lexer、XMLTransfer、MySQLAdminExecutorCreator；三位以上字符的类和方法名称缩写的示例：JdbcUrlAppender、YamlAgentConfigurationSwapper；变量应使用小驼峰形式：mysqlAuthenticationMethod、sqlStatement、mysqlConfig。符合下列条件的局部变量，应参照下列规则命名：除了直接返回方法入参，返回变量使用 result 命名；循环中使用 each 命名循环变量； map 中使用 entry 代替 each；捕获的异常名称命名为 ex ；捕获异常且不做任何事情，异常名称命名为 ignored。方法入参名禁止使用 result、each、entry。工具类名称命名为 xxUtils。配置文件使用 Spinal Case 命名（一种使用 - 分割单词的特殊 Snake Case）。需要注释解释的代码尽量提成小方法，用方法名称解释。 equals 和 == 条件表达式中，常量在左，变量在右；大于小于等条件表达式中，变量在左，常量在右。除了构造器入参与全局变量名称相同的赋值语句外，避免使用 this 修饰符。局部变量不应设置为 final。除了用于继承的抽象类之外，尽量将类设计为 final。嵌套循环尽量提成方法。成员变量定义顺序以及参数传递顺序在各个类和方法中保持一致。优先使用卫语句。类和方法的访问权限控制为最小。方法所用到的私有方法应紧跟该方法，如果有多个私有方法，书写私有方法应与私有方法在原方法的出现顺序相同。方法入参和返回值不允许为 null。优先使用 lombok 代替构造器，getter, setter 方法和 log 变量。优先考虑使用 LinkedList，只有在需要通过下标获取集合中元素值时再使用 ArrayList。 ArrayList，HashMap 等可能产生扩容的集合类型必须指定集合初始大小，避免扩容。优先使用三目运算符代替 if else 的返回和赋值语句。禁止嵌套使用三目运算符。条件表达式中，优先使用正向语义，以便于理解代码逻辑。例如：if (null == param) {} else {}。使用具体的 @SuppressWarnings(&quot;xxx&quot;) 代替 @SuppressWarnings(&quot;all&quot;)。合理使用 @HighFrequencyInvocation 注解，用于聚焦关键方法性能的优化。使用 @HighFrequencyInvocation 注解的时机：请求频繁调用的链路，标注其中高频调用的类、方法或构造器，标注范围精确匹配； canBeCached 属性为 true 时，表示该目标为可复用的缓存资源，例如：数据库连接。标注 @HighFrequencyInvocation 的代码段须严格保证代码性能，以下为标注代码段内的禁止项：禁止调用 Java Stream API；禁止通过 + 拼接字符串；禁止调用 LinkedList 的 get(int index) 方法。注释 &amp; 日志规范：日志与注释一律使用英文。注释只能包含 javadoc，todo 和 fixme。公开的类和方法必须有 javadoc，对用户的 API 和 SPI 的 javadoc 需要写的清晰全面，其他类和方法以及覆盖自父类的方法无需 javadoc。单元测试规范测试代码和生产代码需遵守相同代码规范。单元测试需遵循 AIR（Automatic, Independent, Repeatable）设计理念。自动化（Automatic）：单元测试应全自动执行，而非交互式。禁止人工检查输出结果，不允许使用 System.</description>
	</item>

	<item>
	<title>文档规范</title>
	<link>https://shardingsphere.apache.org/community/cn/involved/conduct/document/</link>
	<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>

	<guid>https://shardingsphere.apache.org/community/cn/involved/conduct/document/</guid>
	<description> 文档标题仅在 title = &quot;xxx&quot; 中出现，文档内部无需主标题（#）；每篇文档结尾留一空行；为避免段落过长，请在句号结尾处换行；标题和内容需要保留空行；为方便阅读，除了最后一列，表格的每列需要严格对齐；表格表头的 \| 与 - 之间需要保留一个空格；数字标记的段落均使用 1. ，由 Hugo 自动生成序号；列表项使用；结尾，最后一项用。结尾；请勿在英文文档中使用中文字符；中英文之间需要空格；图片文件结尾使用语言缩写以区分图片中的不同语言，如：_cn 和 _en。 </description>
	</item>

	</channel>
	</rss>