Bob's Concise Coding Conventions for Software Development
需积分: 10 19 浏览量
更新于2024-09-11
收藏 525KB PDF 举报
"本文档是Bob's Concise Coding Conventions (C3)，由Robert S. Laramee撰写，旨在提供一套简洁的编码规范，适用于通用软件开发。这些规范旨在简单明了，便于记忆，适用于单面纸上。虽然以C++语言为主导，但其原则可应用于任何命令式、面向对象的编程语言。文档还阐述了每条规则背后的背景，包括来源和选择理由，并提供了进一步阅读的参考。此外，文档提出了Bob的软件重开发理论，描述了一个不断重复的软件开发过程，以及为何需要这些编码规范来对抗这种不幸的循环。”
在软件开发中，编码规范（Code Convention）是非常重要的，它们定义了一组标准和最佳实践，帮助团队保持代码的一致性和可读性，提高代码质量，降低维护成本。Bob's Concise Coding Conventions (C3)提供了一系列关键规则，这些规则涵盖了命名约定、代码布局、注释和文档、错误处理等方面。
1. 命名约定：规范通常包括变量名、函数名、类名和常量名的命名规则，如驼峰命名法或下划线分隔等。遵循一致的命名风格可以使得代码更容易理解。
2. 代码布局：规范可能规定了代码的缩进、空格使用、行宽限制等，以确保代码整洁有序。
3. 注释和文档：良好的注释能解释代码的功能、目的和使用方法。C3可能会要求每个函数和类都有清晰的注释，以及如何编写有效的文档字符串。
4. 错误处理：规范会指导开发者如何处理异常和错误，如何时使用try-catch块，以及如何报告错误信息。
5. 代码复用和模块化：鼓励使用函数和类来封装逻辑，避免重复代码，提高代码可维护性。
6. 避免魔法数字和硬编码：建议将常量定义为有意义的变量名，以增强代码可读性。
7. 测试：提倡编写单元测试，确保代码功能正确且易于验证。
Bob的软件重开发理论指出，软件开发往往陷入反复修改和重构的循环，原因是早期的代码质量问题。通过遵循C3这样的编码规范，可以减少因代码不清晰导致的误解，降低重构成本，提高开发效率。这也有助于新成员更快地融入团队，因为他们可以更容易地理解和适应现有的代码库。
编码规范的实施需要团队的共同遵守和持续改进，它不是一次性的任务，而是一个持续的过程。随着技术的发展，编码规范也需要适时更新，以适应新的编程语言特性和最佳实践。通过遵循C3，开发者能够创建出更健壮、更易维护的软件系统，从而打破不幸的软件开发循环。
2 Comments on the Conventions
1. The longer a method is, the less re-usable and the more difficult it is to modify. Also,
the longer a procedure is, the more likely it is to contain bugs and the more difficult it
is to debug. By confining the method to one screen, it gives the programmer (at least)
a chance to keep track of the variables, i.e., the possible values they may contain, from
the beginning to the end of the method. Many engineers resist this rule claiming it
causes a performance slow down. However, software that follows this rule is easier to
optimize with the help of a profiler [12]. Also, shorter methods are better candidates
for inlining. It’s poor algorithm or software design that leads to bad performance
in general. See Chapter 6 on Performance by Dickheiser [1] for a more complete
description of why this is such a good (and important) rule.
2. Too many levels of indentation quickly renders code illegible.
3. This is an interesting rule. Lines that are too long are less legible and more difficult
to debug. This is because, the longer a line is, the more difficult it is for the eyes
to move from the end of one line to the next line. Good publishers us e a guideline
of approximately 66 characters per line of text (so 80 is generally too much) [15].
Reading becomes more difficult as soon as there are more characters on a line. This
is one reason why most newspapers and magazines are multi-column. Furthermore,
object-oriented programming requires multiple windows to be open simultaneously.
Thus having one window open occupying the entire screen makes the mechanics of
the programmer’s job much more difficult [14].
4. Class variables should be easily distinguishable from local variables or other types of
variables.
5. The use of accessor methods enforces encapsulation, an extremely important concept
in object-oriented methodology. (See Wirfs-Brock et al. for more on this topic [20].)
Accessing member variables with methods makes the implementation easy to change,
e.g., a float to an int. This methodology also prevents unwieldy (or even impos-
sible) search-and-replace operations [4, 14].
Another advantage of using accessor methods concerns object state. If class vari-
able assignment is performed exclusively through Set() methods , then you can ensure
that your objects are always in a valid state. This is due to the fact that Set() meth-
ods perform error and bounds checking on the parameters passed to the procedure.
Following this convention leads to very robust code.
6. Accessor methods are the most common to use, as such, it is most convenient when
they are defined at the “top” of the file or class definition.
7. Keeping class variables private enforces encapsulation. Only the class itself should
know about the specific implementation details of its own data [13].
8. It is very nice to be able to tell whether a method is private or public simply by looking
at it (without having to look it up) [14].
9. The more parameters a method takes, the less re-usable it is. We prefer to have
several different implementations of the same method taking different (but only a few)
parameters. In general, too many method parameters, say six or more, is indicative of
a problem(s) with the software design. A long list of parameters probably indicates
that changes to the design are necessary, e.g., the introduction of a new class(es) or
the re-arr angement of existing classes [14] .
3
剩余10页未读，继续阅读
3254 浏览量
180 浏览量
2021-03-06 上传
408 浏览量
2019-04-19 上传
106 浏览量
2010-07-13 上传
deathsoul03
- 粉丝: 0
我的内容管理
展开
最新资源
- Java基因音乐软件开发：节奏与旋律的创新结合
- PHP缩略图类库实现与应用详解
- Web前端资源压缩包：CSS和JS文件整合
- 电子科技大学电路分析课程教案解析
- Go语言开发博客后端教程：Gin框架应用指南
- 深圳市建筑楼块矢量数据包：GIS格式导出与应用
- Angular与Spring Boot整合OIDC认证实践
- CRUDr命令行工具：实现远程API操作的便捷途径
- 掌握Java7开发：官方文档与JDK API全面指南
- Vue3ElementPlus：新一代前端组件库介绍
- 3口交换机设计方案：RTL8305NB与PCB文件
- JS图片上传与取色功能实现详解
- ArcSoft ArcFace Windows X64 V1.1最新版发布
- 掌握Windows核心编程，C++源码分析指南
- Swift技术开发：高效管理通讯录 Contacts
- Java API实现企业级名称和地址数据清洗
