对. 不要扬'短'避'长' 并疏远真正!!参与者, 不要削足适履, 拱手相让主动权, 话语权, 主导权.

外语方便了洋人,害苦了自己,为洋人不惜自残自废,'站不起来',是未战先输人.
外语所致大脑额外负担削弱潜力发挥, 束手束脚, 未战先输阵.
外语疏远国人,失道寡助,未战先输力.
脱离本语, 排挤非英语, 是狭隘的"国际化"

不要让"华人与狗不得入内", 在自己国度, 死灰复燃到"华语与狗语不得参与注释".
自立自强, 丢掉外语包袱, 打破幻想, 突破制裁与围堵.

附议

附议

作为Java开发者，深感命名规范的重要性，Java后端中一般用驼峰命名，前端一般用下划线_命名，不同文件有不同规范，基本上换哪家公司都用这个规范。这个是非常重要的!!!

建议可以先定义编码格式规范。

我觉得纯中文注释就有点太狭隘了，我觉得中英文都有比较好。操作系统用的人越多价值才越大，而且让老外多用甚至免费帮我们开发、维护、升级不好吗？还有就是国外开发者人数远多于中国开发者人数，从“要把我们的人搞得多多的”这点出发，纯中文注释这个不是什么特别好的主意。

至于 @南海 担心的主动权、话语权、主导权，这个其实根本不用担心...这个项目都是国内创建的和国内管理的，开不开源、用哪个协议开源、要不要不让某国/某公司使用，基本都是国内说了算。

统一函数命名规范这个确实值得做一下。

都用中文注释就不必了，让更多人参与进来更好

用中文注释显得很狭隘了，除非你这个系统只供中国人自己玩，要走向世界肯定得用英语，而且这个问题没什么好纠结的。如何提高这个系统的技术含量，吸引全世界更多优秀开发者一起参与才是最重要的

我觉得应该中英文都有才好

格局

“众人拾柴火焰高”，应该保留英文注释，吸引全球developer来参与。

准奏

可以

openharmony面向全球开源，而英语是全球使用最广泛的语言，所以英文还是首选。项目中部分代码是基于其他开源软件开发，该部分代码遵循原项目编码规范，所以体现出来不同的编码风格。具体规则请看： https://gitee.com/openharmony/docs/blob/master/contribute/OpenHarmony-c-coding-style-guide.md

我觉得纯中文注释就有点太狭隘了，我觉得中英文都有比较好。操作系统用的人越多价值才越大，而且让老外多用甚至免费帮我们开发、维护、升级不好吗？还有就是国外开发者人数远多于中国开发者人数，从“要把我们的人搞得多多的”这点出发，纯中文注释这个不是什么特别好的主意。
至于 @南海 担心的主动权、话语权、主导权，这个其实根本不用担心...这个项目都是国内创建的和国内管理的，开不开源、用哪个协议开源、要不要不让某国/某公司使用，基本都是国内说了算。
统一函数命名规范这个确实值得做一下。

@药王 一厢情愿, 形成低效率 疏远真正!!开发者 你所考虑我早靠考虑了, 无需重复"胡服骑射"之类.

用中文注释显得很狭隘了，除非你这个系统只供中国人自己玩，要走向世界肯定得用英语，而且这个问题没什么好纠结的。如何提高这个系统的技术含量，吸引全世界更多优秀开发者一起参与才是最重要的

@panyox 世界天生用英语? "世界"改换语言非首次, 让世界改学汉语何如? 想都不敢想?

“众人拾柴火焰高”，应该保留英文注释，吸引全球developer来参与。

@chinese007 想得美

格局

@jack210481 格局,造型,名词好听,现实脱节.
1.用本语, 自主拓疆, 大航海, 高效本机(本语汉语)运行, 得心应手. (想都不敢想?)
2.用外语, 寄人篱下, 外滩搬运洋滨泾, 低效虚拟机(外语英语)运行, 吞吞吐吐.
自立大航海与寄生洋滨泾, 都是格局 孰高孰低?

openharmony面向全球开源，而英语是全球使用最广泛的语言，所以英文还是首选。项目中部分代码是基于其他开源软件开发，该部分代码遵循原项目编码规范，所以体现出来不同的编码风格。具体规则请看： https://gitee.com/openharmony/docs/blob/master/contribute/OpenHarmony-c-coding-style-guide.md

@Han 棒，原来C语言规范和Java规范一样哦，又学到了

附议，非常赞同，格式统一很有助于参与者进行开发，并减少额外的理解负担

为什么不能考虑双语注释

此处我针对开发人员与软件开发从业者发表观点。若此观点政治不正确或与您的观点相悖，请理性与我讨论，我乐意倾听您的观点、但勿要辱骂，攻击本人。

观点一：注释不应使用中文，但文档应以中文为主。

优秀的项目必然要吸引全球开发者参与进来，社区的力量是无尽的。若要考虑全球开发者，则应提供开发者友好的基础支持，其中英文注释便是开发者友好的方法之一。
由于历史原因，英语几乎成为了编程界语言的事实标准，就如C的ABI一样（笑），我十分理解在坐各位或许心有不忿或是心有不甘，但是否使用英语事实上无关项目的优劣。决定项目优劣的一定是其架构、编程规范、稳定性等方面。并且使用英语并不会影响我们的民族自信心，反而是一味地要求“完全自主”才是民族不自信的表现。
世界上有许多优秀的开源项目，鸿蒙不可避免的要使用它们，而在未来，或许许多国家的人也会积极地加入到鸿蒙的生态中，会与在座的各位一同讨论某个技术问题，会与在座的各位一同为鸿蒙添砖加瓦，会与各位研讨某个功能如何实现————这便是 开源精神 。
这是从发展的角度来看。接下来我们从开发角度来看。
首先我们要讨论的是，英语会对我们对代码和注释的阅读造成障碍吗？事实上并不会，编程中的常用英语只要具有高中知识就能识读八九成，对于一个开发人员来说，阅读常用英文似乎并没有什么障碍。
其次是中文注释造成的编码问题。如您的各个源代码文件中使用的字符集不一致，则在另一台电脑上就可能会出现中文注释乱码的问题。而即使一致，也可能会因为其他电脑默认的字符集与您的不同，造成编码的混乱。再比如，您可能会在GBK中定义中文字符串常量，使用utf-8去加载它。对于刚开始接触编程的朋友来说，这可能会造成一定程度上的困扰。
但中文真的没用了吗 ？并不如此。开发团队应在文档中为中国开发者提供完整的中文技术文档支持和完整的中文开发入门指南，以带领刚入门的朋友能够迅速建立项目以及运行demo。这对于一个优秀的开源项目来说是必要的。
与其纠结是否使用中文注释，不如考虑如何让新手迅速上手您的项目！

观点二：项目确实应该使用统一的代码规范

鸿蒙应该使用统一的代码规范，而不是如@Han 先生所说遵循原项目规范。我不知道您指的原项目是哪一个项目，但我认为统一代码规范、风格是十分必要的，这一点有人总结的很好:

1. 统一的代码规范是代码集体所有权的基础。
2. 统一的代码规范结对编程也会愉快很多。
3. 统一的代码规范可以让大家轮岗更容易。
4. 轮岗机制打通，可以让大家获得内部提升和晋升。

事实上，作为一个开发者，我最在意的是第二点，你们提供的良好的代码规范会让我们编码时感到轻松愉快，而不是把注意力放在这个函数应该是什么样子这方面。

弟弟行为？怎么不建议汉字编程呢？

@panyox 世界天生用英语? "世界"改换语言非首次, 改学汉语何如? 想都不敢想?

@南海 你这NT就不要上网了，先把你键盘的字母换成汉字吧，傻子一样

此处我针对开发人员与软件开发从业者发表观点。若此观点政治不正确或与您的观点相悖，请理性与我讨论，我乐意倾听您的观点、但勿要辱骂，攻击本人。

观点一：注释不应使用中文，但文档应以中文为主。

优秀的项目必然要吸引全球开发者参与进来，社区的力量是无尽的。若要考虑全球开发者，则应提供开发者友好的基础支持，其中英文注释便是开发者友好的方法之一。
由于历史原因，英语几乎成为了编程界语言的事实标准，就如C的ABI一样（笑），我十分理解在坐各位或许心有不忿或是心有不甘，但是否使用英语事实上无关项目的优劣。决定项目优劣的一定是其架构、编程规范、稳定性等方面。并且使用英语并不会影响我们的民族自信心，反而是一味地要求“完全自主”才是民族不自信的表现。
世界上有许多优秀的开源项目，鸿蒙不可避免的要使用它们，而在未来，或许许多国家的人也会积极地加入到鸿蒙的生态中，会与在座的各位一同讨论某个技术问题，会与在座的各位一同为鸿蒙添砖加瓦，会与各位研讨某个功能如何实现————这便是 开源精神 。
这是从发展的角度来看。接下来我们从开发角度来看。
首先我们要讨论的是，英语会对我们对代码和注释的阅读造成障碍吗？事实上并不会，编程中的常用英语只要具有高中知识就能识读八九成，对于一个开发人员来说，阅读常用英文似乎并没有什么障碍。
其次是中文注释造成的编码问题。如您的各个源代码文件中使用的字符集不一致，则在另一台电脑上就可能会出现中文注释乱码的问题。而即使一致，也可能会因为其他电脑默认的字符集与您的不同，造成编码的混乱。再比如，您可能会在GBK中定义中文字符串常量，使用utf-8去加载它。对于刚开始接触编程的朋友来说，这可能会造成一定程度上的困扰。
但中文真的没用了吗 ？并不如此。开发团队应在文档中为中国开发者提供完整的中文技术文档支持和完整的中文开发入门指南，以带领刚入门的朋友能够迅速建立项目以及运行demo。这对于一个优秀的开源项目来说是必要的。
与其纠结是否使用中文注释，不如考虑如何让新手迅速上手您的项目！

观点二：项目确实应该使用统一的代码规范

鸿蒙应该使用统一的代码规范，而不是如@Han 先生所说遵循原项目规范。我不知道您指的原项目是哪一个项目，但我认为统一代码规范、风格是十分必要的，这一点有人总结的很好:
事实上，作为一个开发者，我最在意的是第二点，你们提供的良好的代码规范会让我们编码时感到轻松愉快，而不是把注意力放在这个函数应该是什么样子这方面。

@0xWind 一厢情愿. 被制裁, 不不吸取教训, 一下就进入习惯"全球化"模式, 还是梦不醒.
鸿蒙之所以启动和存在 正是因为制裁 否则无存在必要.
而"全球有多少开发者"之类是幼稚逻辑, 如同说我发明新甜饼, 而全球食品市场规模是几千亿, 只要占有0.1%市场就很客观, 故极有前途, 实质是99%无人问津. 如方案推销之忽悠套路.
定死"英文", 为区区几个洋人 憋屈华人开发人员 无法享受母语的"得心应手" 且脑中来回互译空耗精力.讨好少数人, 或为媚外之心不死. 与出钱买外国留学生来中国, 倒贴利诱, 优待洋大人 牺牲国民利益 如出一辙. 老是方便洋大人, 苦了自己.

习惯性"全球化"教条, 不是脚踏实地. 再看比较:
1.用本语, 自主拓疆, 大航海, 高效本机(本语汉语)运行, 得心应手. (想都不敢想? 宁有种乎?)
2.用外语, 寄人篱下, 外滩搬运洋滨泾, 低效虚拟机(外语英语)运行, 吞吞吐吐.
"自立大航海"与"寄生洋滨泾", 都是格局. 不敢为先, 当然习惯思维定式省力, 且走"全球化""正确""安全".
我看先把系统搞定后, 再谈"全球化" "全球开发者"不请自来. 否则, 预后堪忧.

南海:世界天生用英语? "世界"改换语言非首次, 让世界改学汉语何如? 想都不敢想?

@南海 你这NT就不要上网了，先把你键盘的字母换成汉字吧，傻子一样

@钟志春 我是对牛弹琴.正中我预言 你无种不敢想. 不要自贱, 要自信, 莫媚外. 少出口不逊, 心智发育不全是吧? 请考虑多增加教养.

放到gitee 上面不就是为了方便我们国人的开发者吗,鸿蒙就是为了反对国外制裁才现在放出来的,到现在还有人想着与世界接轨呢?真的想学不会自己翻译啊,国内几十年都过来了,怎么轮到洋大人就不行了?有些人真的这么"贱"?非要去讨好别人? 想学的不会因为是中文注释而放弃,就像我们国内开发者一样,好多看不懂英文的,不是一样可以翻译开发吗,这是我作为一个刚要入门的程序员的发言,人微言轻.自己国家的东西不考虑自己,反而去考虑别人你怎么能站起来,注释用中文有什么影响?乱码又怎样呢?

放到gitee 上面不就是为了方便我们国人的开发者吗,鸿蒙就是为了反对国外制裁才现在放出来的,到现在还有人想着与世界接轨呢?真的想学不会自己翻译啊,国内几十年都过来了,怎么轮到洋大人就不行了?有些人真的这么"贱"?非要去讨好别人? 想学的不会因为是中文注释而放弃,就像我们国内开发者一样,好多看不懂英文的,不是一样可以翻译开发吗,这是我作为一个刚要入门的程序员的发言,人微言轻.自己国家的东西不考虑自己,反而去考虑别人你怎么能站起来,注释用中文有什么影响?乱码又怎样呢?

@starblink 是的，早期的好多框架，默认实现的编码都是拉丁字符集，用的时候经常转化编码,还是一样一样过来的，只有自己强大了，做出东西了，别人才能被你折服，要做自己的领导者，不要做别人的附和者,英文是世界一大语言，但是中文也不差，也是联合国承认的国际通用语言之一.

@starblink 是的，早期的好多框架，默认实现的编码都是拉丁字符集，用的时候经常转化编码,还是一样一样过来的，只有自己强大了，做出东西了，别人才能被你折服，要做自己的领导者，不要做别人的附和者,英文是世界一大语言，但是中文也不差，也是联合国承认的国际通用语言之一.

@ltyeamin 只有自己够强才能获得尊重,取其精华去其糟粕.没必要这么极端对吧,只要一说反对老外的东西,就有人跳出来,那你不要用微软的系统啊,不要用老外开发的语言啊之类,感觉和ZZ一样,老外就不用我们的东西吗?什么好用就用什么,国内开发注释用中文这不是非常正常的吗?你要是觉得不行那你就用英文就是了,用中文还能照顾下我们这些渣渣,非常感谢...

放到gitee 上面不就是为了方便我们国人的开发者吗,鸿蒙就是为了反对国外制裁才现在放出来的,到现在还有人想着与世界接轨呢?真的想学不会自己翻译啊,国内几十年都过来了,怎么轮到洋大人就不行了?有些人真的这么"贱"?非要去讨好别人? 想学的不会因为是中文注释而放弃,就像我们国内开发者一样,好多看不懂英文的,不是一样可以翻译开发吗,这是我作为一个刚要入门的程序员的发言,人微言轻.自己国家的东西不考虑自己,反而去考虑别人你怎么能站起来,注释用中文有什么影响?乱码又怎样呢?

@starblink 实际上，对于开源系统，由于其开源属性，并没有实施制裁。即使一些开源系统如linux突然宣布闭源，我们也可以使用闭源之前的版本随意修改，这是站在巨人的肩膀上。
想要深入了解计算机系统，或是深入开发，您无可避免地需要查阅英文资料——就如您大学时查阅论文一样。
操作系统的开发必定是复杂而困难的，我们支持国产系统是为了让国产系统更加好用，为了提升，您认为不懂英语，连论文都没翻过几页的“开发者”能够为这个系统做出什么贡献呢？或许生态也算是一种贡献吧，但这都是建立在不断完善系统本身的基础上的。
我现在正在关注的一个开源项目正在发愁如何为他的游戏引擎加入国际化支持，在努力地适配各国语言（要知道，ui中的文字处理向来是一个难点），在虚心地接受世界各地的issue和pr，他的引擎正在健康的成长————我希望这个系统亦能够茁壮成长。
不接受国外的优秀项目和经验，闭门造车只是在走历史的老路。
伴随您学习深入，自会明白其中道理。
事实上，我提出了开发团队应支持完整的中文文档——本身也应该支持，作开发者，与您关系最为密切的，对您帮助最大的向来是文档，而不是注释。
以上。
祝您学业有成！

@starblink 是的，早期的好多框架，默认实现的编码都是拉丁字符集，用的时候经常转化编码,还是一样一样过来的，只有自己强大了，做出东西了，别人才能被你折服，要做自己的领导者，不要做别人的附和者,英文是世界一大语言，但是中文也不差，也是联合国承认的国际通用语言之一.

@ltyeamin 对. 必须先让人折服. 只有系统完成且显示优势, 才会有老外跟进, 锦上添花. 即便是国人也是此观望心态, 故系统首先需"自强".
若看不到前途, 没老外会投入, 除非花钱买"老外开发者"(犹如买来留学生), 但这失去"开源"意义. 吸引"老外开发者"是系统本身的价值, 而不是靠英语. 若无看到价值和前途, 再完美英语也无用, 不定反被"洋大人"看成急切巴结心态.

此处我针对开发人员与软件开发从业者发表观点。若此观点政治不正确或与您的观点相悖，请理性与我讨论，我乐意倾听您的观点、但勿要辱骂，攻击本人。

观点一：注释不应使用中文，但文档应以中文为主。

优秀的项目必然要吸引全球开发者参与进来，社区的力量是无尽的。若要考虑全球开发者，则应提供开发者友好的基础支持，其中英文注释便是开发者友好的方法之一。
由于历史原因，英语几乎成为了编程界语言的事实标准，就如C的ABI一样（笑），我十分理解在坐各位或许心有不忿或是心有不甘，但是否使用英语事实上无关项目的优劣。决定项目优劣的一定是其架构、编程规范、稳定性等方面。并且使用英语并不会影响我们的民族自信心，反而是一味地要求“完全自主”才是民族不自信的表现。
世界上有许多优秀的开源项目，鸿蒙不可避免的要使用它们，而在未来，或许许多国家的人也会积极地加入到鸿蒙的生态中，会与在座的各位一同讨论某个技术问题，会与在座的各位一同为鸿蒙添砖加瓦，会与各位研讨某个功能如何实现————这便是 开源精神 。
这是从发展的角度来看。接下来我们从开发角度来看。
首先我们要讨论的是，英语会对我们对代码和注释的阅读造成障碍吗？事实上并不会，编程中的常用英语只要具有高中知识就能识读八九成，对于一个开发人员来说，阅读常用英文似乎并没有什么障碍。
其次是中文注释造成的编码问题。如您的各个源代码文件中使用的字符集不一致，则在另一台电脑上就可能会出现中文注释乱码的问题。而即使一致，也可能会因为其他电脑默认的字符集与您的不同，造成编码的混乱。再比如，您可能会在GBK中定义中文字符串常量，使用utf-8去加载它。对于刚开始接触编程的朋友来说，这可能会造成一定程度上的困扰。
但中文真的没用了吗 ？并不如此。开发团队应在文档中为中国开发者提供完整的中文技术文档支持和完整的中文开发入门指南，以带领刚入门的朋友能够迅速建立项目以及运行demo。这对于一个优秀的开源项目来说是必要的。
与其纠结是否使用中文注释，不如考虑如何让新手迅速上手您的项目！

观点二：项目确实应该使用统一的代码规范

鸿蒙应该使用统一的代码规范，而不是如@Han 00000000 先生所说遵循原项目规范。我不知道您指的原项目是哪一个项目，但我认为统一代码规范、风格是十分必要的，这一点有人总结的很好:

事实上，作为一个开发者，我最在意的是第二点，你们提供的良好的代码规范会让我们编码时感到轻松愉快，而不是把注意力放在这个函数应该是什么样子这方面。

@0xWind OpenHarmony项目有统一的编码规范，并且已经在文档中描述了；但是也有例外情况，比如说引入的其他项目开源软件，摘录如下：

例外

在不违背总体原则，经过充分考虑，有充足的理由的前提下，可以适当违背规范中约定。
例外破坏了代码的一致性，请尽量避免。“规则”的例外应该是极少的。

下列情况，应风格一致性原则优先：
修改外部开源代码、第三方代码时，应该遵守开源代码、第三方代码已有规范，保持风格统一。

其他规范请参考：https://gitee.com/openharmony/docs/blob/master/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md

@0xWind OpenHarmony项目有统一的编码规范，并且已经在文档中描述了；但是也有例外情况，比如说引入的其他项目开源软件，摘录如下：

例外

在不违背总体原则，经过充分考虑，有充足的理由的前提下，可以适当违背规范中约定。
例外破坏了代码的一致性，请尽量避免。“规则”的例外应该是极少的。
下列情况，应风格一致性原则优先：
修改外部开源代码、第三方代码时，应该遵守开源代码、第三方代码已有规范，保持风格统一。
其他规范请参考：https://gitee.com/openharmony/docs/blob/master/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md

@Han 明白了，是我没仔细看

中文就比用了，不过命名风格统一倒是应该。

这又何必？本来就是希望建立一个全球生态，何必设置门槛？

这又何必？本来就是希望建立一个全球生态，何必设置门槛？

@我的煎蛋呢 用中文就是设置门槛吗？未必吧

@我的煎蛋呢 用中文就是设置门槛吗？未必吧

@CoolLoser 难道不是？先进软件开发技术本就是西方发展起来的，我们后进学习的，何必为了证明自己而故意设置门槛？况且源码开发，本来就是英文开发，写注释用英文更方便，不用切换输入法。

@CoolLoser 难道不是？先进软件开发技术本就是西方发展起来的，我们后进学习的，何必为了证明自己而故意设置门槛？况且源码开发，本来就是英文开发，写注释用英文更方便，不用切换输入法。

@我的煎蛋呢 关键在系统是否有价值, 若无价值, 用不用英语也无"洋大人"参与.
汉语以至任何语言并非"门槛". 是否跨越英语"门槛"或汉语"门槛", 全看是否有利.
用英语反而给自己设置"门槛",无法得心应手, 反倒疏远真正使用者,如鱼离水,失道寡助.
且用英文方便洋大人苦了自己,结果没引来洋大人,搞成"汉语与狗语不得参与注释".
科技领先,天下共逐,并无永恒. 排斥汉语的全球化,是狭隘的全球化.

切换输入法更是小事, 盲打者不费吹灰之力, 若不能盲打则英文也举手维艰.
汉语至少省去大脑来互译额外消耗而制约潜能发挥. 潜能发挥是科技领先关键, 不然永远只能亦步亦趋当好好学生.

大可不必

开发者您好，感谢关注OpenHarmony项目。
Openharmony面向全球开源，为了更好的支撑全球各地区开发者参与，代码注释使用了英文，同时提供了中文文档。
我们提倡统一的代码风格，代码规范具体规则请参考：
https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md

OpenHarmony刚刚起步、持续建设中，存在很多不足之处，欢迎广大开发者反馈Issue、提交PR，共同建设OpenHarmony。
非常感谢~