一方面,因为需要不断的切换输入法,当然很难受。
如果一个编程语言,所有的符号都是中文符号,而且文字之间也不需要空格分割符合中文习惯。整体编程输入包括各种光标移动需求也能全程在输入法下完成,自然可以。
但是,很显然,输入法跟自动完成机制也存在一定的冲突,毕竟两者是相似的东西。
要是真正意义上让中文输入方便,不但要全程开输入法,还得把输入法集成代码自动完成相关功能。
另外,getxxx,setxxx,isxxx之类的方法是有其语义作用的,在某些场合能直接映射到field,这个功能又如何增加到中文支持呢?那应该还是需要在语言层面直接增加一些中文解析才行。
总的来说,使用中文的机制还不完善,单纯让变量使用中文会显得不伦不类。而更完善的方式似乎也没有人设计。
如果能更好的解决中文标识符相关的一系列使用体验方面的问题,我个人也是支持在编程中使用中文的。
不过,再怎么同意,使用中文代码也会仅限于公司代码,只要公司要求写中文,我肯定不犹豫。
自己写代码,尤其是开源代码的话,肯定不愿意让这个代码的生命周期只活动于国内,程序员本来可以无国界交流,注释写中文不影响流通,但标识符写成中文就让它局限在国内了,多多少少会不方便。
其实没啥大问题,主要问题就是环境。因为常用的库和关键字(这个相对好处理)都是拉丁字母表示的(不一定是英文)。你用中文做变量名和函数名就必然面临混杂的问题,看起来和用起来就不怎么舒服。
所以这不是出了易语言么?关键字和库函数全部用中文,那你非用英文做名字也别扭……
但是为什么常用的语言和库都是用拉丁字母的呢?我觉得除了历史的惯性之外,你们就不考虑下输入法的问题?别人要用你的类库还要专门去学怎么输入中文除了整天在中文互联网扯淡的谁还用?
这里再顺便说下我对所谓中文编程的态度好了。我对于现代的支持Unicode的语言中用不用中文作为函数、变量、命名空间、类型等等东西的命名是完全持开放态度的,甚至认为用中文总比用拼音好,毕竟拼音压根儿不是一种文字。
我所反对的是那些觉得程序是用英文写的(压根儿不是),以及拉丁字母是中国人学编程的障碍的这种神棍……
在我看来,易语言不管最终成不成,反正是做了个尝试。但是其实从效果来看,已经有力地证明了26个字母才不是编程的障碍……
你在gb18030编码下写下了一串汉字变量名
第二次打开时你的编辑器默认用utf8打开了
你想要重新用gb18030编码打开,却点成了用gb18030保存
于是你再选择用gb18030编码打开,看到了满屏幕的锟斤拷
这不是笑话,这是我自己的亲身经历
不过我没用中文变量,我只是console.log打印了一些中文log
写代码这块,用二十六个字母能解决的事情尽可能别引其他编码的字进来
比如下面这段batch,原始编码是shift-jis的日文,在utf8下打开后...wow
REM //------------------------------------------------------------------------------ REM // 僾儘僙僗婲摦 REM //------------------------------------------------------------------------------ REM // AMDaemon婲摦 start /MIN %DAEMON_EXE% -f -c %DAEMON_CONFIG_COMMON% %DAEMON_CONFIG_SERVER% %DAEMON_CONFIG_CLIENT% timeout 5 REM // AMDaemon偺夝憸搙愝掕偱夋柺偑墶偵側偭偰偟傑偆偺偱廲偵愝掕偡傞 REM // 斀帪寁廃傝偵夞揮偡傞 REM // 0 : 0搙 REM // 1 : 90搙 REM // 2 : 180搙 REM // 3 : 270搙 %ROTATEDISPLAY_EXE% 3 REM // 傾僾儕働乕僔儑儞婲摦 start /WAIT %APP_EXE% -nolog REM //------------------------------------------------------------------------------ REM // 僾儘僙僗嫮惂廔椆 REM // 傾僾儕偺堎忢廔椆摍偵傛傝amdaemon.exe偑廔椆偟偰偄側偄応崌偑偁傞 REM // 偙偺応崌僙僈僽乕僩傊慗堏偱偒側偄偺偱kill偟偰偍偔 REM //------------------------------------------------------------------------------ taskkill /im %DAEMON_EXE% > nul 2>&1
我看了一下不少高赞答案,似乎都没提到一个很严重的问题:字符集和乱码的问题?
事实上这个原因才是大多数稍微正经的编程语言仅使用ascii字符的原因,因为ascii字符兼容性最好。更进一步,很多团队里,别说代码了,连注释都是不允许出现非ascii字符的。
尤其是中文:gd2312/gb18030、gbk、utf8几大套本身就会乱码,再考虑带不带bom,又要一堆的适配。然后从编辑器到编译器再到符号表最后到调试器,一条龙全都要做大量的额外适配工作。最后,搞这么一堆东西出来,有什么实质上的改变吗?
你要说英文不好?那你用a、b、c、d总会吧?然后在每次用到的旁边加上中文注释,不照样可以吗?
你要是说你敲代码时懒得加注释,那我觉得你三分钟热度过了之后,也会懒得用中文写代码的。
总是有人觉得支持了unicode就可以很爽的用汉字当变量名了?
感谢评论区的提醒,我来构造一个更有趣的场景:
假定某语言完全支持了unicode,然后你在完成某个需求的时候,你需要分别调用几个:法国人、德国人和意大利人写的库。那你怎么办呢?
首先,确保你的电脑上装了这几个文字的多语言支持(包括显示和输入)。
然后,你需要分辨哪个库分别是用哪个语言写的(希望你能在学习英语之外,抽空多学学各国文字),如果某个作者来自于多语言区(例如说瑞士同时同行德法意三语),那他在一个文件内,可能同时混用多种语言来命名。当然,一般情况下,接口级API会有些demo,你照着copy paste一下也问题不大。
接着,你的某个类需要派生自底层的一个用意大利语写的类,派生接口嘛,函数名要保持一致,所以在很漂亮的中文代码里,突然间就飘着几句意大利文。当然,如果运气不好的话,很可能也要飘着一点法文和德文的。
再接下来,当你写完了功能,发现执行有点不对,需要调试器跟踪进那个库的时候,各个函数是干嘛的,应该在哪个函数上打断点,这就麻烦你准备个多语言的字典随时备查了。假如某个德国人写的库的底层实现里,还依赖了阿拉伯人写的库,那如果你的电脑没事先装好的话,麻烦你先退出调试过程,安装语言支持包,然后继续。不然,那就是一片乱码了(当然,对我个人的外语水平而言,不乱码的阿拉伯文也是乱码)。
最后,当你排除万难完成了这个需求,并且把你代码提交之后。一个韩国人来问你,要使用你这个库的话,需要安装哪些语言支持——希望你在文档里写清楚。
这是一个多充实多美好的一天啊。
有人还不服气,那我就随便构造一个这样的类吧:
类 小功能 : 继承自 Kleine_Funktion 继承自 Funçãopequena 继承自 Piccola-funzione 整型 测试功能 () : 空实现 intero Cominciare () : #........... nulo inicialização (Fragmento Nome) : #.......... Zeichenfolge Alter () : #..............
语法是随便混合几种语言的,翻译是找谷歌翻译的,自己看看可读性是不是非常棒?
哪怕我允许你们用翻译软件,试试看要花多少时间才能找到正确的语言版本?