《狂人C》的某些观点和做法不被某些网友所赞同，但彼此又处于相互无法说服的状态。
为使读者能有更广阔的视野而不至于被圉于《狂人C》的一家之言，兹将双方观点收集于此，供读者参考。也欢迎有识之士评点讨论。
一、关于标识符（参考链接： 之275楼始）
反方看法：
老外看不懂；
多年的习惯造成看拼音组合的变量感觉别扭；
使用汉语拼音对一个要走向社会的程序员来说是相当不好的；
汉语拼音和和if/while/include等英文单词混用，大脑有时会短路；
拼音会降低了代码的可读性，歧义太多，汉语同音词太严重,很难实现标识符的唯一性；
用拼音缩写不如用拼音全写，用拼音全写还不如用中文……不过UCN标识符不见得被编译器广泛支持，而且会产生潜在的兼容性问题；
简单的英文单词大家还是认识的，所以使用英文单词做标识符不会产生阅读困难。
《狂人C》观点：
用何种方式命名并没有标准答案，关键是代码究竟是给谁看。如果不准备给老外看，为什么要用英文单词?况且多数初学者的英语水平未必就能达到能让老外理解的曾度；
习惯既然可以养成，也可以改变；取一个不恰当的名字给思维带来的扭曲其实更别扭
公司里也不都是要求一律用英文单词命名；
应该把if/while/include等英文单词用汉语的思维方式来理解；
英文词汇量有限同样无法实现标识符的唯一性，可能必然会导致num1,num2,……这种最恶劣的命名方式，这对思考是有害的；
汉语同音词严重的现象确实存在，但是如何用拼音命名也从来没被认真地研究过，这个问题应该有合适的解决办法；
“用拼音缩写不如用拼音全写，用拼音全写还不如用中文”，的确如此；
“不过UCN标识符不见得被编译器广泛支持，而且会产生潜在的兼容性问题；”，第一个问题是编译器的问题，不是程序员本身的问题。潜在兼容性问题也不属于程序代码本身的范畴；
不应该把懂得英语作为学习程序设计的门槛，那是作茧自缚；编程的水平和英语水平毫无关系；使用汉语拼音可以降低学习门槛，增加代码可读性。
作为书籍应该向读者灌输命名规范的意识，但没有建立命名规范的义务，况且这种规范在国内并没有公认的标准。
C99容许标识符可以由更广泛的文字（ISO/IEC 9899：1999，Annex D）组成。这一点强烈地友好地提示我们编程应该尽量使用自己的母语，为什么我们自己要自设门槛、作茧自缚呢？须知语言是思想的外壳，那种用不通的英语单词写出的代码，在思想上必然是变态的。
二、关于VLA(variable length array)的翻译（相关链接：VLA(variable length array)该如何翻译？ 召唤英语帝、 ISO党 ）
反方看法：
应该翻译为“可变长数组”；
这里“variable”是形容词；
对于“int a[m+1];”这样的情形，m+1不能作为变量看待，所以“变量长度数组”并没有准确地概括VLA的本质。
C语言任何类型的对象的长度(sizeof)在对象的生命周期内大小不变，所以无论是翻译成变长数组还是翻译成变量长度数组，都可能会引起歧义。
翻译成变量长度数组，同样可能让人觉得VLA在其生命周期内长度可变。
“可变长数组”更顺口；
可不可变是角度不同，站在调用者的角度，传入不同的值，其数组长度不同，可变；在被调用者的角度，无论你传什么进来，我一旦确定长度后在这个栈中就不能更改，不可变。
《狂人C》观点：
应该翻译为“变量长度数组”；
这里“variable”是名词；
“可变长数组”给人的印象是数组的长度可变，但实际上VLA的长度并不能变化；
非VLA数组的定义用“整数类型常量表达式（integer constant expression）”描述其长度。与之对应，VLA是用整数类型变量表达式描述长度的数组；
“变长数组”更容易被理解为VB里的那种“动态数组”；
“变长数组”会给人先入为主的数组长度可变的印象，而“变量长度数组”则不会这样；
阅读(3370) | 评论(0) | 转发(0) |
