我看了这一段文字 ：“代码规范”可以分成两个部分：1.代码风格规范。主要是文字上的规定，看似表面文章，实际上非常重要。2.代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。,有这个问题：软件工程整个流程是庞大的，而代码规范我认为是细节问题。如此庞大的的流程为何要如此注重代码规范。我查了资料,有这些说法【1. 使代码遵从工具。

2. 坚持使用一种命名模式。如果你打算用匈牙利命名法，那就坚持并广泛使用，否则将适得其反。使用匈牙利命名法来记录数据，而不是存储类型；记录普遍事实，而不是临时条件。

3. 使用断言来记录先决条件（preconditions）和后置条件（postconditions）。

4. 别缩写英文单词。确切来说，别缩写成稀奇古怪的形式。在脚本引擎中，有个变量名叫“NME”，这让我非常抓狂！它应当叫“VariableName”。

5. C语言标准运行时库的设计不是很优秀。别去效仿它。

6. 别写“聪明”的代码；当代码出现问题，维护代码的程序员没时间去理解你的聪慧。（编注：这条建议即为：编写可维护的代码，详情可参见《》中的第8点。）

7. 理解编程语言特性的设计初衷，使用这些特性去做它们适合完成的工作，而不是它们能做到的工作。例如：别把异常当做一般的流控制机制来使用（即便你能做到），而应该用它们来报告错误。别强制把接口指针转换成类指针，即便你知道这样没问题。

8. 按功能单元划分源码树，而不是按组织结构。比如：我目前所在团队中，有2个根子目录的名字是“Frameworks”和“Integration”，这是两个团队的名字。不巧的是，Frameworks团队名下有一个叫“Adaptor”的子目录，而“Adaptor”却是Integration的子目录，这就非常令人迷惑。同理，（如果）有着相同子目录的不同的子树，有些是客户端的组件，有些是服务端的组件；有些是管理组件，有些是非管理组件；有些是处理型组件，有些是非处理型组件；有些是零售组件，有些内部测试工具。这就会乱七八糟的。】

根据我的实践,我得到这些经验：当编写软件工程流程是主要注重工程的流程中所需要的，对于代码规范部分并不很重视。 但是我还是不太懂,我的困惑是：代码规范主要是应用于编程语言中，例如：Python.Java。而软件开发流程中我想不必太重视。.