蛙蛙推荐：关于开发规范的一些讨论.doc

看了一些网上的VB.NET C#等的编码规范，感觉只是一些命名与定义上的规范而已，并不是一个完整的开发规范。
请大家看看以下的现象：
    实现同一个功能，比如说编辑一行数据，并把数据保存到数据库中。
这个功能，给三个程序员，可能会出三种编码结果，实现的功能都一样。
但是，当互相查看对方的代码时，很不习惯，谁都能讲出对方那种编码方式的不足之处
但是，倒底哪种方式是最优的呢，也可能是按不同情况下，哪编码方式是最优？
似乎，国内大多数设计人员，并不注重这些问题，但我认为，这确实是一种很严肃的问题。我想各位同仁也有和我一样的感觉。
 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

我想集本坛众多经验丰富的好手，共同总结出一种对于实现常规功能最优的设计方案。
 

我不知道我的想法大家能否认同，不知道做这件事是否有意义。
 

请大家批评指正，也请志同道合的同仁一起讨论。
 

join_gu@hotmail.com

顾君彦
应该没有这样严格的规范。
 

不可能也不现实来实现这种规范：
1）规范应该是简单明了的，定义道函数级别，太多，并且也很容易不全。
2）编码本身每一个人都有自己的特点，在容易理解的继承上，个人可以保持自己的一些优秀的风格，没有必要所有都雷同。
3）太多了，记不住。并且太多规范版本的升级，对于一个稍微大一点的规模来说，是一种灾难。
 

按照我的经历，大约可以从几个方面来克服这个问题：
1）有一套言简意赅的编码规范就够了，不要指望你的开发人员能想当年背诵毛主席语录一样熟练。
2）每一个阶段完工以后，都有一个riview meeting, 比如High Level Design完毕之后，拿出来riview一下，大家（范围自己定义）看看有什么问题，提一提意见，有问题回去修改。Coding完了之后，有code review,同样的方法。所有的review recond都要保留，每一个reviewer都同意之后，大家才可以通过，大家对质量都负有责任。
 

如果每一个人都开放一点，大家的水平很容易就上去了。
谢谢，我论为，一个项目，不需要编码人员思考太多的问题，也无需更多的技巧。
这些事都不是一个普通的编码人员所要做的。而软件设计理想状态下需要让编码者
100%的按照设计进行工作。而对于一个软件来说其中有70%以上的操作方式或实现都

能够进行规范，以做为实现标准。这样的话，对于管理，开发，都很好，何乐而不为呢？
个人意见：
没有意义。
1。 如你说三个人有三种编码方式。你想统一一种好的，最优的。你怎么知道不会出现第四种，而它才是最优的。所以可以讲只有更好，没有最好
2。 程序员是人不是机器，大量的规范让他遵守，按模板来编程。这应该是CASE做的事，而不是程序员。我认为编码也是一种创造性劳动。
我认为有命名的编码规范就够了，只要开发人员互相之间能看懂就行了。
---

最好的办法是自己（公司）定一套命名规则，规范一点，命名规范不致于别人看不懂就行，至少要让维护人员和测试人员能看懂。
有一种面向软件工程的命名规范的选择策略，可以参考。（只是我个人的意见）
1、如果算法已经确定好，并且抽象类型不多，可以用匈牙利方法。
2、如果算法已经确定好，而且抽象类型很多，所有类型变量均采用2—3个单词简称，用下划线进行连接。很类似于老UNIX那套办法。但函数名称可以与类型、变量方法不同。
3、如果算法还不是很确定，而且抽象类型很多，那么建议类型、变量名称一般不要用简称，也不要怕名称过长，可以给长的类型名称取别称。定义时候用长名称，声明的时候用别名短名称。如果用其他方法，算法的研制可能根本就出不来。——人毕竟不是上帝。在阅读代码时候如果还要费脑筋，新算法是很难研制的。

4、算法还不确定、抽象类型不多，那么用匈牙利方法和第二种方法都可以。——但这种情况很少见，——算法没确定以前，很难知道抽象类型多不多。
变量类型不重要, 重要的是变量的用途.
所以命名的底线是让变量的功用一目了然.
其他就是各自发挥了

命名规则是必要的，我相信大家都比较肯定（当你看别人的代码的时候就深有体会了）。至于用哪种规则可以小组商定，不要把它当成枷锁就是了。匈牙利命名规则或是posix方式都很好，只是习惯的问题，其实一个清晰的命名都不可能太简短，最终的目的都是“一目了然”。
这个需要平时认真的去做，不能偷懒
比如，变量的定义要增加类型的缩写，intaaa,straaa，类似这样的，可以清楚的知道变量的类型

还有在写代码的同时要注意加注释，否则时间长了，可能自己都不知道是什么意思了
1.减少代码重用率，尽量将功能封装成函数或者过程
2.变量函数命名规范化
3.代码格式清晰，避免错乱不堪
4.一定要多写注释，这一点非常重要，一个再厉害的人过2个月再去看自己没有注释的上万行代码，嘿嘿，结果可想而知
5.编程之前必须已经非常清楚自己下面所作的内容以及各个模块之间的关系，换句话说，系统分析已经比较完善
6.千万别想在一个版本中完成所有的功能，应该尽力完善几个关键的部分，但是可以留下接口
7.系统一定要具有一定可扩展性，否则下一个版本的工作量将会非常大

代码简练，增加运行速度，努力使用最佳的实现方法。
1 将功能封装成函数或者过程,保存为一个文件，用到了include
2 变量函数命名规范化
3 编码格式化,尽量少嵌套if语句
4 加注释
5 多保存，多备份

6 设立多个版本
tdl982324(石井坚) 的解决之答非常有效，希望楼主在今后的编码中多多积累。
 

另外，再说几点：
1　编码之前，先进行设计，也就是算法流程设计，最好可以有一个流程框图之类的东东，可以在脑子中，当然也可以在纸面上。
2　有了第一步，你就有了程序的框架。接下来，先不要编码，而是首先写注释。这个注释就是你的流程了。
3　然后开始编程。编程就是对你的注释的代码化翻译。
4　编程的过程中，注意变量的命名规范，当然还有函数、方法、类的命名规范。这些规范随语言的不同而不同，个人喜欢VC的一些规范。一个好的规范有助于提高代码的可读性。
5　对于复用性代码，写成函数，最终形成函数库。这是你在编码过程中最最重要的一个积累，是你的财富。这笔财富多了以后，别忘记建立一个索引。没事的时候看看，它会在以后的编码中大幅度地提高效率。还有，就是对这些函数库精益求精。
6　用ASP的时候，会用到很多别人的代码。要把别人的东西转化成自己的东西，一定要搞懂，不能应付了事。

7         最后，祝楼主节日快乐。
 

用ASP的时候，会用到很多别人的代码。要把别人的东西转化成自己的东西，一定要搞懂，不能应付了事。
－－－－－－－－－－－－－－－－－
感悟很深，最近老是在看ASP的源码，可老是觉得自己的水平并没有什么提升，昨晚回家时，想到底为什么呢？
答案就是上面的那句话！！！
编程一定要动手！动手！动手！动手！动手！动手！动手！动手！动手！

先實現,再優化(因為我是初學者,^_^)
首先应该保证代码的可维护性
其次才是代码的运行效率

如果代码写的晦涩难懂以后维护起来就是个大麻烦
关于数据库的设计，如果系统较大，表比较多的话，这点很重要。
一旦数据库设计有较大的问题，页面修改起来将很麻烦。
另外一点要提高SQL查询语句的效率。

最后要注意系统安全问题！
重复是精简的：
1.减少代码重用率，尽量将功能封装成函数或者过程
2.变量函数命名规范化
3.代码格式清晰，避免错乱不堪
4.一定要多写注释，这一点非常重要，一个再厉害的人过2个月再去看自己没有注释的上万行代码，嘿嘿，结果可想而知
5.编程之前必须已经非常清楚自己下面所作的内容以及各个模块之间的关系，换句话说，系统分析已经比较完善
6.千万别想在一个版本中完成所有的功能，应该尽力完善几个关键的部分，但是可以留下接口
7.系统一定要具有一定可扩展性，否则下一个版本的工作量将会非常大
 

 

 

补充：
一个项目 所有的 注释格式，缩近大小 都要一样..

作为asp来说 少用session
规范的问题很大,需要有完整的文档支持
还有要团队的共同约束,有核心进行审核,抽查

没有放之四海皆准的规范或约束,根据自己的实际情况确定吧,当然大家共同的认识才是最重要的