小议代码的巨量注释=>LTS

前言：

关于对代码进行巨量注释（比如不少于三分之一）这个话题，想吐槽的地方太多了，竟一时不知道从哪说起好，但积怨已深，不吐不快！以下观点仅代表minghu9本人观点。

0.

为什么对于同一个问题（暂时限制在IT领域），为什么不同人观点差距很大呢？
我总结了两点：
1. 屁股决定脑袋，所处的位置决定思考的角度
2. 个人经历、所处环境，潜移默化地影响观点

1.如果注释就能就能解决问题

假设使用注释的直接目的就是为了使代码易读，根本目的就是是代码易开发、易维护。
这是本文讨论的重要前提之一。

那么首先，注释是自然语言，它有自然语言的优缺点：易写易读但不精确
诚然你可以不断改进注释的方法技巧、使它描述代码更精确，那么按照这条思路，最好的情况就是最后形成了一个统一的精确的强大的注释语言标准Union-Note(它的中文版本叫做“大一统”),而按照某些激进的‘代码嵌入到注释里’的“权威人士”的想法，我们完全可以只写注释不写代码，既然注释已经形成了一个统一的精确的强大的语言标准，那么我们就可以为它编写一个注释解释器，通过解析注释自动生成代码，然后最好还要编写debugger，支持注释语言“Union-Note”的底层原地调试。

这样以来，人们只需要花时间编写一流的注释，因为不需要写代码，所以从代码量所占比例（0%）来看，开发成本为零。另外还有注释语言的debugger，一旦注释发生错误，还可很方便地调试，因为只有注释没有代码，所以即使手工调试、二次开发也很方便。

总之一切都很好，自动阅读注释、自动按照注释编写代码、自动检查注释错误，方便开发，易于维护，注释就实现了它最终的目的。
然后这时你回头一看，突然发现自己只不过发明了另一种Lisp，所有的搞的一切都扔停留在1957年的水平
（写到这突然想到了一句话：
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
）
仅凭这一点，巨量注释代码这条路就是没有前景的路，没有前景的路就是死路。

另外更重要的是，注释是一种语言，被注释的代码本身也是语言，为什么我们要用一种语言注释另一种语言？！
这里就要考虑个人经历、所处环境给人的影响*，就像硬件思维与软件思维截然不同（那些强行说它们一样的人就像认为兔子和石头都是客观存在物体，因此是一样的东西一样（虽然不错，但没有实际意义））

1. 在计算机较底层的经历是一切以机器为考量、代码是面向机器的（微指令、机器指令、汇编语言、毫不客气地把C也算上）比起逻辑上的正确、代码本身的易读，机器执行的效率是最优先考量的。因此写出来的东西往往很丑陋，（即使这样，在代码有一个基本可读的情况下，很熟练的人依然可以看懂）所以需要注释、而且需要巨量注释，这时注释的作用是用最笨的人工的方法提供一个人类可读的抽象层，将面向机器的语言(代码)转为面向人的语言（注释），从他们的工作环境来看，这一点可以理解。
2. 而当这些人从事计算机抽象较高的层次时，不自然地把原来的这些底层工作的习惯带了过来（这时他们往往已经成为了某种程度的权威人士）他们忽视了在那个层次里的语言比之原来，已经做了至少一个抽象层了（虽然做的并不好，这以后再讨论），较高层次的开发语言本身就是面向人（也就是开发者）（典型代表是那些动态语言python,ruby etc.）的，而不是机器，所以再强行注释无异于画蛇添足。

2.既然注释不能就能解决问题

所以比较现实的方法是代码自文档化，

• 用空行、回车、缩进、控制逻辑结构；
• 用变量名（包括函数名、类名、常量名等）自解释，表示具体含义
• 在关键点、歧义处加精炼的注释

事实上这也不是什么新词，它也只是个凑活用的方法，因为最大的限制来源于那些语言在从底层抽象的时候就没有很好地考虑过代码自文档化的问题（虽然他们标准库的函数命名很有规律，但也仅此而已）（python这方面值得一提，它正是通过缩进与换行描述代码结构，因此它以可读性极强，开发效率最高）

代码自文档化这方面需要做的还有很多，我能想到的是

1.可以形成一个统一的类似MarkDown式的编写标准

突然被一件事打断，思路断了，以后再写
几个周过去了。。。

接着，现在考虑一个合适的命名标准

首先，对于静态类型的语言，有名的是匈牙利命名法，自带类型检查，然而强类型和过于繁琐是硬伤

我认为
1. 一般地，所有的变量都要用正规的缩写
2. 当描述一个动作一个动作对象的二元词组时，宜用小驼峰

    getInt =>get An Interger
    wStr =>write a String
    //缺点是对于部分缩写有争议（因为人对自然语言的进行手工压缩时采取的协议不同，发生冲突时的，再散列方法也不同）

3. 存在一个对象的单元组时，全部大驼峰

    PQ=>PriorityQueue
    SynStackArr=>Syncronized  Stack Array//对于没有约定俗成的缩写，适当全拼以保证足够的汉明距离

1. 存在一个动作的单元组时小写

关于现行一些语言的编写结构体

1 Assembler
类似Pascal,从头写到尾，语句开头没有任何缩进

DATA        SEGMENT 
message1        DB  'Name:ZHUANGYUAN',0DH,0AH,'$'
message2        DB  'QUIT:q/Q',0DH,0AH,'$'
message3        DB  'ID:13030211023',0DH,0AH,'$'
message4        DB  0DH,0AH,'Input: ',0DH,0AH,'$'
message5        DB  0DH,0AH,'ASCII is:',0DH,0AH,'$'
DATA        ENDS

CODE        SEGMENT 
   ASSUME   CS:CODE,DS:DATA
START:      
MOV     AX,DATA
MOV     DS,AX
MOV     DX,OFFSET message1
MOV     AH,09H      
INT     21H     
MOV     DX,OFFSET message2
MOV     AH,09H
INT     21H 
MOV     DX,OFFSET message3  
MOV     AH,09H
INT     21H

QUIT:   
MOV DX,OFFSET message4  
MOV AH,09H
INT 21H 

MOV     AH,01H          
INT     21H
CMP     AL,'Q'
JZ      EXIT
CMP     AL,'q'
JZ      EXIT

MOV     message5,AL                     
MOV     DX,OFFSET message5  
MOV     AH,09H
INT     21H 

MOV     SI,OFFSET message5
MOV     AL,DS:[SI]
AND     AL,0F0H         
MOV     CL,4
SHR     AL,CL
CMP     AL,0AH          
JB      f2      
ADD     AL,07H

f2:     
ADD     AL,30H      
MOV     DL,AL           
MOV     AH,02H
INT     21H
MOV     AL,DS:[SI]
AND     AL,0FH          
CMP     AL,0AH
JB      f3
ADD     AL,07H

f3:     
ADD     AL,30H
MOV     DL,AL           
MOV     AH,02H
INT     21H
LOOP    QUIT

EXIT:
MOV     AH,4CH  
INT     21H

CODE        ENDS
END         START