Xuan Wu
@htwx 调试进展: 初步确定是由于在[分行读取词典文件时](https://github.com/program-in-chinese/CTS_Typewriting/blob/master/%E6%BA%90%E7%A0%81/%E6%95%B0%E6%8D%AE%E8%AF%BB%E5%8F%96.cts#L521), 使用了"\r\n"分割, 但是(猜测是由于git上传时去掉了"\r")我本地的词典文件行末只有"\n". 导致"基础词库"完全没有被读入.
加减号的意思是? 为避免这帖太长, 在[项目](https://github.com/program-in-chinese/CTS_Typewriting/issues)里提了对应的两个问题([读取词典](https://github.com/program-in-chinese/CTS_Typewriting/issues/3), [返回5个](https://github.com/program-in-chinese/CTS_Typewriting/issues/2)).
也许可供参考, [ローマ字入力時の日本語識別子入力補完プラグインの 開発](http://jssst.or.jp/files/user/taikai/2017/FOSE/fose3-1.pdf)开发了辅助插件以改进IDE对输入日语命名的支持: > In this research, we develop a plug-in that reduces the burden on programmers when input Japanese identifier. The complication of software development projects in recent years...
源自[此问](https://www.zhihu.com/question/316530679/answer/640177016), 发现这个JS实现的本地输入法: [sxei/pinyinjs](https://github.com/sxei/pinyinjs), 也许可参考其字库和实现.
@lsby 先把参考资料留着： https://github.com/zyctree/vscode-google-pinyin 另可参考易语言内置输入法功能：  待确认问题： - 是否/如何与 IDE 的补全功能集成，比如选字等等 - 中英混输比如`get名称`
@kenpusney 多谢! 顶楼确实非常针对Java中的中文命名. 主要的考虑是, 即使新的中文编程语言现在出现, 很可能要5-10年才能成熟和推广. 那么在这之前以及之后的一段时间, 当今的英文编程语言还会占据很大一部分市场(考虑到现有软件的生命期), 因此探讨一下英文编程语言中的中文风格也是有益处的. 另外, 这些风格也可能影响新中文编程语言的设计. > 用OO方式写代码的时候大概都会是SVO（主-谓-宾）的形式，也即，.（）。这样其实也就不会出现什么“方法”和“变量”命名冲突了。 顶楼有一点"方法/函数命名尽量用动词开头", 也是出于类似考虑. 但是变量名可能难以做到完全不用动词开头. 因为即使是名词短语也很可能用动词开头. 但方法和变量名即使在英文代码中也是无法一眼区分的, 因此主要关注的还是区分类名(上面采取的是后缀"类") > 另外，类或者getXxx、setXxx 之类的，既然你期望引入中文编程，就没必要一定拿Java这堆模型来设计语言。比如，直接引入“属性（property）”，远比定义一堆getter/setter好得多。 很同意. 如果是新的中文编程语言, 绝对不会用这个get/set前缀. > 另外临时变量用“某（some）”，“临时（temp）”这种前缀其实在现在的编程实践中都不是一个很值得推荐的做法。更不要试图用匈牙利命名法来给输入和理解增加负担。 很同意. 个人也认为匈牙利命名的缩写部分在现在的命名风格中已经不再推崇了. 不过临时变量的命名也许值得探讨一下....
看到第二个链接里的`logOff`而不是`logOut`, `signOut`而不是`signOff`; `logOn`而不是`logIn`, `signIn`而不是`signOn`; 还有`canceled`而不是`cancelled`, 就呵呵了. 还没细看wiki的页, 不过之前想过在所有编程语言中使用一套尽可能一致的中文命名方法, 避免英文命名在不同历史阶段留下的各种不同风格. 也算一种后发优势吧. > 某些时候若用大小写携带某些语义有用，也要另想办法 除了之前提到的`区分类/方法/变量/常量`的目的, 其他还有什么情况呢?
颜色的规范难度恐怕不比词缀小, 个人感觉和IDE功能耦合有点大. 现在想来, [之前](https://github.com/program-in-chinese/assembler-in-chinese-experiment/blob/master/src/cn/org/assembler/constants/%E5%AF%84%E5%AD%98%E5%99%A8%E5%B8%B8%E9%87%8F.java)没有特别区分常量命名, 好像也没什么问题, 语义上就比较清楚了. 而且还有编译期检查.
@ofooo > 或者加个后缀“常数” 顶楼提到加类似前缀, 主要考虑一般所有常量排在一起, 看起来可能更整齐, 如下. 不过下划线的确不大自然. ``` private static final String 常量_单字节累加寄存器名 = "AL"; private static final String 常量_单字节计数寄存器名 = "CL"; private static final String 常量_单字节数据寄存器名 = "DL";...
@cflw 多谢分享经验! 非常高兴看到中文命名的实践项目: - https://github.com/cflw/cflw_py - https://github.com/cflw/cflw_cpp 组里有些中文命名的API项目(比如[简繁转换](https://github.com/program-in-chinese/zhconverter), [汉化JUnit4](https://github.com/program-in-chinese/junit4_in_chinese), [英汉词典](https://github.com/program-in-chinese/english-chinese-dictionary)), 感觉这对推广中文命名颇有益处, 因为用户就可以发现接口中文命名的优势(见[v2用户反馈帖](https://www.v2ex.com/t/480623)). 如果有兴趣/打算开发一些针对常用功能的库(Python爬虫/功用库?)的话, 欢迎创建issue/repo(邀请已发). 英文命名规范发展了数十年, 相信中文命名规范也需要在实践(尤其是团队开发)中磨砺和总结. 希望对细节问题的切磋探讨不会妨碍合作实践. 个人认为, 从可读性考虑, 感觉英文缩写需要开发者先了解英文命名规范, 对新手来说门槛高一些. 另外IDE本身也有一些辅助作用. 比如"用命名分类区分不同函数的功能/作用范围", 现在IDE的自动补全/outline视图等等会通过不同图标区分显示. 是否需要用命名承载这些功能也是个课题.