屁

evil idea: "automatic comma insertion" just like ecmascript's "automatic semicolon insertion", insert a comma on line break when applicable. btw some previously-in-my-mind other idea about next-line parentheses, or to be...

just to mention that deno 1.0 has been released https://deno.land/v1 "design mistakes" in Node as stated by the author, and their correspondence in current version, might be worth checking.

https://en.wikipedia.org/wiki/Naming_convention_(programming) https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions 一些关于英语大小写、下划线乱象的参考（与微软爸爸的标准，里面有很多关于合成词缩写词的鲜活的例子，男人看了会沉默） 感觉虽然中文在这方面先天优势，不会乱不会纠结，但是某些时候若用大小写携带某些语义有用，也要另想办法。

> 不妨用颜色或者其它办法区分单复数？ 单复数与类我是偏向加词缀，常量、变量什么的区分倒是可以考虑颜色【然而话说色盲色弱选手 也可以考虑粗体、下划线（毕竟下划线还是以前的专名号 的确这么一波讨论下来觉得发展中文编程首先要实现更高级的代码编辑器的渲染，至少跟代码里的标识符要有关……

@ofooo > 用颜色的想法不知道怎么想出来的。。。。写代码的时候如何编辑一个文字的颜色？？？？难道要点击鼠标改颜色吗～～～谁写代码还得来回用鼠标。。。。有点异想天开～～～ 当然不是啦……语法高亮听说过么……要手动编辑么…… 我说的就是一种稍微高级点的语法高亮，编辑器渲染的时候搞点鬼。 比如约定，用英文字母来打头，大写C大头为类名，那么代码里是`C某类`，渲染出来就删掉那个影响视觉的`C`，变成变色的`某类`，常量就写作`K某常量`，渲染作另一个风格的`某常量`，等等。 易语言纯文本不也是`.`打头关键字嘛，渲染出来加蓝，虽然编辑的时候完全是结构化编辑是另一回事了。 再进一步，如果做插件抱上了强如vscode, intellisense的大腿，一边编辑一边后台执行分析，一个token是在哪儿声明有什么性质，都能得到了，就直接自动加颜色加风格了，一个意思。

看了上面这些标准，有所感悟，不过关于前缀我的想法还是，不做太细的要求，取大众惯例的核心就好。 比如OOP起来，成员函数随时都在调用，前面是`.`后面是`()`，还要加个f就累赘了…… 只要覆盖常用情况，难以表述又原有惯例的，如C类，I接口，m成员变量（有m了除此之外都是成员函数了），然后c常量，Ee为枚举类、数据，我觉得就差不多了。 一些高频词，比如表示“个数”的时候n（俗话说得好n个），“是否”用下b，“集合、数组"的时候a（或者t，l，这里就不太统一了，看是否根据实际数据结构而变）。 getter、setter可以用“取、置”。s这个字母实在是太容易撞，set（设置、集合）、string、struct，不宜写入规范。 剩下就可以不再强求英文字母，自行命名稍长两字准确一点也好，也避免规范跟个人灵活使用撞车难以避开的情况。

@nobodxbodon 对于Collections，我的想法是“容器类”。 并不是一对一照搬翻译（虽然也不是强行反直译，联想到易语言本土化命名的一些努力，有价值但确实有点反直译反现行译名）。翻译总是去找那一个最合适表达的嘛。 这个容器不一定要直接联想到Container，取“装东西”之意，类也不光是class，实际上它是个命名空间但是里面装了一些class（实际上里面还有一层命名空间……），这里类表示“容器这一类的东西”，顺便也可以表达集合概念“里面装的是容器class们”，这个“类”其实对应的是“s”。至于里面的class，就都按各自数据结构来命名了，英文命名也没见每个都吊一个XxxClass。

@nobodxbodon 作为vb用户表示是并不喜欢某些大小写用法的。 具体到中文命名的类与实例。 比如容器类，首先就不赞同List list，Vector vector这种做法。容器数据结构名称作为类，其实例对象，装的是啥东西，名字就叫啥，最多是单复数问题，可以前加“所有”，“诸”，后缀“集”，“们”，中英结合缀个s都没毛病，为何要去跟数据结构撞名？ 大概是只有在毫无目的测试容器类库的时候才找不到名字，此时放心地列表1列表2好了，甲乙丙天地人ABC都可以…… 有意义的类，其实例，我觉得仍然，如果一定要跟类名撞，多半是命名完全不达意。稍加修饰指明这是这类的什么实例，强制更易读，甚至觉得这设定挺好（汉字优势就在于多加两个字就能精确很多，哪怕变量普遍四五字，表意精确也不过长，正是潜力所在）

@jeffreybaoshenlee 哇，看了下你的那个repo，我其实也有相同想法，整理一些可优化的IT术语翻译。目标也很有共鸣，不刻意不勉强，就去找最合适的。 不过放在github上似乎有点不太方便有想法的（平常人/中文语文水平比较高的人）提供意见…… 甚至想过做一个极简的，术语翻译想法分享页，带吃瓜群众投票什么的。（日常空想 至于这个.NET库标识符【其实就是随手一选，抽象一点来说就是“订立可行的翻译某种语言的标准库的流程”】，应该是一个人或者少数几个人组团来完成并且定稿的，因为毕竟是个整体还是要保证某种一致，而且目的是比较务实的。

@nobodxbodon 同一个单词大部分情况下是要统一的，但是ArrayList这个情况我觉得是比较例外的，只要这两个单词某种程度上结合了、变成常用术语、含义有引申了，都可以考虑给一个更准确的新名。 以及上面其实也提到了大写版后缀“类"的做法，也算是一种偏严格的但是读起来不一定通的语义转换做法。我的看法总的来说就是不能一刀切，要看情况具体讨论。