写子程序的注意事项
来源:互联网 发布:前端后端数据库 编辑:程序博客网 时间:2024/04/29 10:23
核对表:高质量的子程序
大局事项
q 创建子程序的理由充分吗?
q 一个子程序中所有适于单独提出的部分是不是已经被提出到单独的子程序中了?
q 过程的名字中是否用了强烈、清晰的“动词+宾语”词组?函数的名字是否描述了其返回值?
q 子程序的名字是否描述了它所做的全部事情?
q 是否给常用的操作建立了命名规则?
q 子程序是否具有强烈的功能上的内聚性?即它是否做且只做一件事,并且把它做得很好?
q 子程序之间是否有较松的耦合?子程序与其他子程序之间的连接是否是小的(small)、明确(intimate)、可见(viaible)且灵活(flexible)的?
q 子程序的长度是否是由其功能和逻辑自然确定,而非遵循任何人为的编码标准?
参数传递事宜
q 整体来看,子程序的参数表是否表现出一种具有整体性且一致的接口抽象?
q 子程序参数的排列顺序是否合理?是否与类似的子程序的参数排列顺序相符?
q 接口假定是否已在文档中说明?
q 子程序的参数个数是否没超过7个?
q 是否用到了每一个输入参数?
q 是否用到了每一个输出参数?
q 子程序是否避免了把输入参数用为工作变量?
q 如果子程序是一个函数,那么它是否在所有可能的情况下都能返回一个合法的值?
■ 创建子程序最主要的目的是提高程序的可管理性,当然也有其他一些好的理由。其中,节省代码空间只是一个次要原因;提高可读性、可靠性和可修改性等原因都更重要一些。
■ 有时候,把一些简单的操作写成独立的子程序也非常有价值。
■ 子程序可以按照其内聚性分为很多类,而你应该让大多数子程序具有功能上的内聚性,这是最佳的一种内聚性。
■ 子程序的名字是它的质量的指示器。如果名字糟糕但恰如其分,那就说明这个子程序设计得很差劲。如果名字糟糕而且又不准确,那么它就反映不出程序是干什么的。不管怎样,糟糕的名字都意味着程序需要修改。
■ 只有在某个子程序的主要目的是返回由其名字所描述的特定结果时,才应该使用函数。
■ 细心的程序员会非常谨慎地使用宏,而且只在万不得已时才用。
- 写子程序的注意事项
- 写代码的注意事项
- ATL写ActiveX的注意事项
- 写串口程序的注意事项
- 写技术博客的注意事项
- 写技术博客的注意事项
- 写技术博客的注意事项
- 写技术博客的注意事项
- 写技术博客的注意事项
- 写技术博客的注意事项
- web写文件的注意事项
- c++写模板的注意事项
- 写.c源文件的注意事项
- 写 Java 代码的注意事项
- 第一次写topcoder的注意事项
- 程序员写简历的注意事项
- 写一个名为 &total 的子程序,返回一列数字的和
- 编写子程序的原则
- pku1821 dp的优化
- LINUX-NIS
- TSP问题之回溯法 cpp实现
- 在linux下搭建libcap开发环境:
- 显示桌面图标不见了如何恢复
- 写子程序的注意事项
- Windows Azure入门教学系列 (二): 部署第一个Web Role程序
- 关于指针的释放
- Windows Azure入门教学系列 (三):创建第一个Worker Role程序
- OllyDBG (OD )入门系列
- [翻译]High Performance JavaScript(001)
- 拷贝件或者文件夹
- Windows Azure入门教学系列 (四):使用Blob Storage
- Windows Azure入门教学系列 (五):使用Queue Storage