代码规范文档
- 格式:doc
- 大小:71.50 KB
- 文档页数:8
市民融合服务云平台代码开发规范V0.1修订记录1.引言1.1编写目的编写本文档主要目的是:使市民融合服务平台能以标准的、规范的方式设计和编码。
通过建立编码规范,以使每个开发人员养成良好的、统一的编码风格和习惯,提高程序的可靠性、可读性、可修改性、可维护性和一致性,保证软件产品的质量。
1.2适用范围市民融合服务平台相关人员1)架构师2)开发人员1. 工具使用规范2.1开发工具要求3. 文档规范1.项目编号、项目命名规范。
无论是项目编号,还是项目名称(项目简称、项目全称),每个项目都有一个统一的编号、简称、全称。
我们的项目名称为市民融合服务云平台,项目编号为(“待续”)2.文档编号、文档命名不规范。
每份文档都有一个编号,如某项目文档编号由WD_PA_PRO_YYMMDD_姓名拼写组成,其中WD表示公司名称,PA表示项目编号,PRO表示文档类型、此处指的是项目过程书,YYMMDD表示日期,姓名拼写表示姓名的拼音三个字母组成,不足三位的补“X”或“Y”。
而在使用过程中,有的不知道PA是表示项目编号,有的日期格式写成YYYY-MM_DD,有的随意增加其它内容。
文档命名通常由编号与文档类型名称组成,如项目过程书文档规范的命名是“WD_PA_PRO_YYMMDD_姓名拼写项目过程书”。
3.文档页眉、页脚规范页眉页脚使用公司的Logo ,它是公司的标志,也说明这一份文档不仅是代表项目组,也是代表公司的形象。
而页眉、页脚上的logo或标志应该是固定的,项目组不应该随意性修改。
4.文档的版本标识规范根据配置管理的定义,文档控制级别为中、低的文档是不需要进行版本控制的,比如那些一些临时性的、一次性的、中间性的文档,而文档控制级别较高的文档要进行版本管理。
在一些控制级别的文档中,如:用户需求说明书,概要设计说明书等,无论修改有多少次,没有留下版本记录。
有的文档标识有版本记录,一个版本对应一份文档,比如《用户需求说明书V1.0.doc》、《用户需求说明书V1.1.doc》等,这样维护文档容易出错。
Introduction 介绍本文提供的Python代码编码规范基于Python主要发行版本的标准库。
Pyt hon的C语言实现的C代码规范请查看相应的PEP指南。
这篇文档以及PEP 257(文档字符串的规范)改编自Guido原始的《Pyth on Style Guide》一文,同时添加了一些来自Barry的风格指南。
这篇规范指南随着时间的推移而逐渐演变,随着语言本身的变化,过去的约定也被淘汰了。
许多项目有自己的编码规范,在出现规范冲突时,项目自身的规范优先。
A Foolish Consistency is the Hobgobli n of Little Minds 尽信书,则不如无书Guido的一条重要的见解是代码阅读比写更加频繁。
这里提供的指导原则主要用于提升代码的可读性,使得在大量的Python代码中保持一致。
就像PEP 20提到的,“Readability counts”。
这是一份关于一致性的风格指南。
这份风格指南的风格一致性是非常重要的。
更重要的是项目的风格一致性。
在一个模块或函数的风格一致性是最重要的。
然而,应该知道什么时候应该不一致,有时候编码规范的建议并不适用。
当存在模棱两可的情况时,使用自己的判断。
看看其他的示例再决定哪一种是最好的,不要羞于发问。
特别是不要为了遵守PEP约定而破坏兼容性!几个很好的理由去忽略特定的规则:1. 当遵循这份指南之后代码的可读性变差,甚至是遵循PEP规范的人也觉得可读性差。
2. 与周围的代码保持一致(也可能出于历史原因),尽管这也是清理他人混乱(真正的Xtreme Programming风格)的一个机会。
3. 有问题的代码出现在发现编码规范之前,而且也没有充足的理由去修改他们。
4. 当代码需要兼容不支持编码规范建议的老版本Python。
Code lay-out 代码布局Indentation 缩进每一级缩进使用4个空格。
续行应该与其包裹元素对齐,要么使用圆括号、方括号和花括号内的隐式行连接来垂直对齐,要么使用挂行缩进对齐。
java编码规范文档# Java编码规范文档。
一、前言。
小伙伴们!当我们一起在Java的世界里畅游时,要是大家都按照一套约定俗成的编码规范来写代码,那我们的代码就像训练有素的军队一样,整齐又高效。
这份规范就是我们在Java编程旅程中的小指南,让我们的代码既容易理解,又方便维护。
二、命名规范。
# (一)包(package)命名。
1. 包名应该全部小写,用点(.)分隔单词。
就像你的小包裹要摆放得井井有条一样,包名也得规规矩矩。
例如:`com.example.myproject`,这看起来多清爽。
如果写成`Com.Example.MyProject`,那就像穿着奇装异服的士兵混在整齐的队伍里,很不协调。
# (二)类(class)命名。
1. 类名采用大驼峰命名法(UpperCamelCase),每个单词的首字母大写,不要包含下划线或者其他奇怪的符号。
这就好比给每个班级取一个正式又响亮的名字。
比如:`MyFirstClass`,而不是`my_first_class`或者`my first class`。
那些奇怪的写法就像给班级取个让人摸不着头脑的名字,可不好。
# (三)方法(method)命名。
1. 方法名采用小驼峰命名法(lowerCamelCase),第一个单词小写,后面每个单词首字母大写。
这就像给方法这个小助手取个清晰明了的名字,方便我们知道它是干什么的。
例如:`calculateSum`,而不是`Calculate_Sum`或者`CALCULATESUM`。
要是写成后面那种,就像一个小助手穿着奇装异服,你都不知道它是来帮忙做什么的。
# (四)变量(variable)命名。
1. 变量名同样采用小驼峰命名法。
变量就像一个个小盒子,我们得给它们取个能让人一眼就大概知道里面装什么东西的名字。
像`studentName`,你一看就知道这个变量可能是用来存学生名字的。
要是写成`student_name`或者`STUDENTNAME`,就有点让人迷糊啦。
阿里巴巴代码规范阿里巴巴代码规范是由阿里巴巴集团内部制定的一套代码编写规范,旨在提高代码的可读性、可维护性和可扩展性。
下面是我为您整理的阿里巴巴代码规范的要点,详细内容请参考阿里巴巴的官方文档。
1. 命名规范:- 类名使用大驼峰命名法,变量名和方法名使用小驼峰命名法。
- 常量名全部大写,多个单词之间用下划线分割。
- 包名全部小写,多个单词之间用点分割。
2. 代码排版:- 使用4个空格缩进。
- 大括号独占一行,并且与前面的代码保持一个空格的间隔。
- 方法之间空一行,逻辑较为紧密的代码块之间可以不空行。
3. 注释规范:- 类、接口、枚举和注解需要写明作者、创建时间、版本和功能描述等信息。
- 方法、变量和逻辑复杂的代码需要添加注释,以说明其作用和用法。
4. 异常处理:- 必须捕获异常,并及时进行处理,避免出现未处理的异常。
- 不允许捕获Exception或Throwable,应该捕获具体的异常类型。
- 在finally块中释放资源或进行清理操作。
5. 并发控制:- 使用并发包中的线程安全类,如ConcurrentHashMap、CopyOnWriteArrayList等。
- 不使用synchronized关键字直接修饰方法,而是使用Lock接口进行加锁和解锁。
6. 日志管理:- 使用日志框架进行日志输出,如log4j、slf4j等。
- 日志输出需要有明确的日志级别。
- 使用占位符可以避免字符串连接操作,提高性能。
7. 代码重构:- 代码需要经常进行重构,保持代码简洁、高效、可复用。
- 删除未使用的变量、方法和类。
- 移动、重命名、提取方法等操作需要谨慎,避免产生不必要的副作用。
8. 引用规范:- 避免重复引用相同的类,可以使用import static来静态导入某个类的静态成员。
- 不要使用通配符导入,尽量明确导入的类。
以上是阿里巴巴代码规范的一些要点,希望可以对您编写高质量的代码有所帮助。
详细规范请参考阿里巴巴的官方文档。
代码大全txt 《代码大全txt》第一章:引言1.1 文档概述1.2 目的1.3 背景1.4 读者对象第二章:代码质量与维护2.1 代码质量的重要性2.2 代码规范2.2.1 命名规范2.2.2 缩进和对齐规范2.2.3 注释规范2.2.4 异常处理规范2.3 代码复用性和可维护性2.3.1 函数的设计原则2.3.2 类的设计原则2.3.3 模块的设计原则2.3.4 代码重构技巧第三章:代码调试与测试3.1 调试与测试的重要性3.2 常见的调试技巧3.2.1 打印调试3.2.2 断点调试3.2.3 日志调试3.3 单元测试与集成测试3.3.1 单元测试的概念3.3.2 测试驱动开发(TDD)3.3.3 持续集成与自动化测试3.4 异常处理与错误处理3.4.1 异常处理的原则3.4.2 异常处理的技巧3.4.3 错误处理与错误码规范第四章:代码安全与防御4.1 代码安全性的重要性4.2 常见的安全漏洞4.2.1 SQL注入4.2.2 XSS攻击4.2.3 CSRF攻击4.3 防御措施与开发规范4.3.1 输入验证4.3.2 输出编码4.3.3 权限验证4.3.4 日志记录4.3.5 安全审计第五章:代码性能与优化5.1 代码性能的重要性5.2 常见的性能问题5.2.1 网络延迟5.2.2 数据库查询优化5.2.3 循环优化5.3 性能测试与调优方法5.3.1 压力测试5.3.2 排查性能瓶颈5.3.3 代码优化技巧5.4 并发与多线程编程5.4.1 并发编程的概念5.4.2 多线程安全问题与解决方法5.4.3 锁的使用与注意事项第六章:代码版本管理与团队协作6.1 代码版本管理的重要性6.2 常用的代码版本控制工具6.2.1 Git6.2.2 SVN6.3 团队协作与代码合并6.3.1 分支管理6.3.2 冲突解决与合并策略6.4 代码的发布与部署6.4.1 发布流程与环境6.4.2 部署工具与自动化第七章:代码文档与知识管理7.1 代码文档的重要性7.2 常见的代码文档形式7.2.1 注释文档7.2.2 API文档7.2.3 设计文档7.3 知识管理与分享7.3.1 文档管理工具7.3.2 知识库与博客7.4 文档维护与更新策略7.4.1 版本控制7.4.2 反馈与改进第八章:总结8.1 本文档的贡献8.2 未来的发展方向8.3 结语以上是关于《代码大全txt》的文档,介绍了代码质量与维护、代码调试与测试、代码安全与防御、代码性能与优化、代码版本管理与团队协作、代码文档与知识管理等方面的内容。
代码规范一、命名习惯(1)包名一般用小写字母和少量的数字组成。
(2)类名和接口名一般由一个或几个单词组成,遵循“驼峰规则”。
(3)方法名除了第一个单子首字母小写外,其他单词都是首字母大写,与类名取名类似(4)属性名如果是基本数据类型的变量一般小写,引用数据类型的变量一般与类名取名类似。
局部变量可以简写.命名规范1.公共包:mon.层次名;例如:mon.model;mon.dao;mon.service;mon.action;2.基本包:com.litsoft.模块名.层次名;例如:com.litsoft.teacher.model;com.litsoft.teacher.dao;com.litsoft.teacher.service;com.litsoft.teacher.view;com.litsoft.teacher.view.action;3.类名:每个层次相对应的Java类都以层次名称结尾.例如:model层:TeacherDao层:TeacherDaoService层:TeacherService;Action层:TeacherAction;4.方法名:1.每个层次之间主要调用的方法名必须相同:例如:Action层:getById;Service 层:getById;Dao 层:getById2.方法前缀规定:1.保存方法必须以save/insert/add开头2.删除方法必须以delete开头3.更新方法必须以update方法4.查询方法必须以get开头3.执行条件规定:<1>方法执行时,如果有条件限定以By+条件;如果限定条件有多个,则用And连接例如:1.通过Id查询:getById2.通过Id删除:deleteById3.通过类型和状态查询:getByTypeAndStatus()<2>方法执行后影响对象如果只有一个:a〉对象属性操作(主要针对更新操作):方法名定义:update+属性名+限定条件例如:updatePasswordById()b>对象操作:可以省略对象名称方法名定义:直接方法前缀+限定条件<3> 方法执行后影响多行数据,方法定义:方法前缀+List+限定条件例:getListByid()二、类中的代码规范1.类之前加文档注释/***** Description :知识点Action <br />* 定义知识点相关操作的Action** <pre>* +----------------------------------------------------- * 更改历史* 更改时间更改人目标版本更改内容*+-------------------------------------------------------- * July,6 2012 吕悦 1.00 创建** </pre>** @author吕悦 <a href="mailto:lvyuely@">E-mail:lvyuely@ </a><ahref="tencent://message/?uin=596688499"> QQ:596688499</a> */2.方法前的注释:(1)注释方法名称及方法用途。
java开发规范文档
以下是一个简单的Java开发规范文档:
1. 命名规范:
- 类名使用首字母大写的驼峰命名法,如:MyClass
- 方法名以小写字母开头的驼峰命名法,如:myMethod
- 变量名使用小写字母开头的驼峰命名法,如:myVariable - 常量名使用全大写字母和下划线的命名法,如:
MY_CONSTANT
2. 缩进和格式:
- 使用4个空格进行缩进
- 在每一行结束后使用分号
- 在大括号的前面留空格,如:if (condition) {
- 在逗号后面留空格,如:int a, b, c;
3. 注释规范:
- 使用JavaDoc格式注释解释类、方法和变量的功能和用法 - 在代码中适当添加注释,解释代码的实现逻辑
4. 异常处理:
- 使用try-catch-finally语句块来处理异常
- 不要使用空的catch块,尽量提供明确的异常处理逻辑
5. 最佳实践:
- 使用面向对象的思想设计代码结构
- 避免使用全局变量,尽量使用局部变量和参数传递数据
- 不要在循环中创建对象,尽量在循环外部创建对象
- 使用合适的数据结构和算法来提高性能
这只是一个简单的Java开发规范文档,实际中可以根据团队的需求和项目的特点进行适当的修改和补充。
idea代码标准格式化一、概述代码格式化是编程过程中必不可少的一部分,它有助于提高代码的可读性和可维护性。
在 IntelliJ IDEA 开发环境中,代码格式化是一个常用的功能,可以帮助开发者按照一定的规范对代码进行整理和美化。
本文档旨在为开发者提供一份适合 IntelliJ IDEA 的代码格式化标准,以帮助大家更好地编写和维护代码。
二、代码格式化规则1. 缩进:使用 4 个空格进行缩进,不要混用空格和制表符。
2. 行长度:单行代码不宜过长,建议不超过 80 个字符。
3. 方法命名:使用 camelCase 命名法,首字母小写,后续单词首字母大写。
变量命名也应遵循此规则。
4. 注释:合理使用注释,对重要的代码段进行说明。
5. 空格:在运算符两侧、逗号后、分号前添加空格。
6. 括号:不同类型的括号要配对使用,左括号应与右括号齐平。
7. 类型提示:在函数和变量名后添加适当类型的提示。
三、特殊情况处理1. 在处理 XML、JSON、YAML 等格式的文件时,可以使用 IDEA 自带的格式化工具或者手动调整格式,以确保文件格式符合规范。
2. 在处理涉及特殊语法结构(如循环、条件语句等)的代码时,应按照相应的语法规则进行格式化,以保证代码结构的清晰和易读。
四、实践操作步骤1. 在 IntelliJ IDEA 中打开需要格式化的代码文件。
2. 快捷键操作:可以使用快捷键 `Ctrl+Alt+L`(Windows/Linux)或`Cmd+Option+L`(Mac)进行快速格式化。
3. 手动操作:在菜单栏中选择 `Code` > `Reformat Code`,根据提示进行操作。
4. 在格式化过程中,IDEA 会自动调整缩进、换行、空格等,以符合代码格式化标准。
5. 完成格式化后,可以检查代码是否符合预期,如有需要可以进行进一步的调整。
五、注意事项1. 确保安装了合适的 IntelliJ IDEA 插件,如 ESLint、Checkstyle 等,以提高代码质量。
java 代码规范Java代码规范是指在Java程序设计中遵循的一些规则和约定,旨在提高代码的可读性、可维护性和可移植性。
遵守代码规范可以帮助团队成员更好地理解和协作开发,提高代码的质量和可靠性。
本文将围绕Java代码规范展开讨论,包括命名规范、代码风格、注释规范、异常处理等方面的内容。
一、命名规范1.包名规范包名应该全小写,连接符可以使用小写字母和下划线,不推荐使用数字。
包名应该能够清晰地表达包所包含的内容,不要使用太长或者太短的包名。
2.类名规范类名应该采用驼峰命名法,首字母大写,类名应该能够清晰地表达类的用途,不要使用太长或者太短的类名。
如果类名由多个单词组成,应该遵循每个单词首字母大写的命名规范。
3.接口名规范接口名应该采用驼峰命名法,首字母大写,接口名应该能够清晰地表达接口的用途,不要使用太长或者太短的接口名。
如果接口名由多个单词组成,应该遵循每个单词首字母大写的命名规范。
4.变量名规范变量名应该采用驼峰命名法,首字母小写,变量名应该能够清晰地表达变量的用途,不要使用太长或者太短的变量名。
如果变量名由多个单词组成,应该遵循每个单词首字母小写的命名规范。
5.常量名规范常量名应该全大写,单词之间使用下划线分隔,常量名应该能够清晰地表达常量的用途,不要使用太长或者太短的常量名。
6.方法名规范方法名应该采用驼峰命名法,首字母小写,方法名应该能够清晰地表达方法的用途,不要使用太长或者太短的方法名。
如果方法名由多个单词组成,应该遵循每个单词首字母小写的命名规范。
二、代码风格1.缩进和空格缩进使用4个空格,不使用tab键。
在操作符前后使用空格,增强代码的可读性。
2.大括号的使用在类定义、方法定义、控制结构等的语句块后面使用大括号,增强代码的可读性。
3.代码行长度每行代码的长度不要超过80个字符,超过80个字符的代码应该使用换行符进行分割。
4.引号的使用字符串常量应该使用双引号,字符常量应该使用单引号。
编写易于阅读的代码文档一、前言代码文档是开发人员在编写代码时必不可少的一部分。
它记录了代码的功能、结构、使用方法等信息,有助于其他开发人员理解和使用代码。
本文将介绍如何编写易于阅读的代码文档,以及一些常见的编写规范和技巧。
二、选择合适的文档格式首先,我们需要选择合适的文档格式。
一般来说,常见的代码文档格式有Markdown、HTML、PDF等。
其中,Markdown格式简单易懂,适用于大部分代码文档的编写。
它支持常规的文本编辑,同时也可以插入代码片段、图片等内容,非常适合代码文档的编写。
三、编写规范的文档结构在编写代码文档时,我们需要遵循一定的文档结构,以便读者能够快速地找到所需信息。
一般来说,代码文档的结构可以分为以下几个部分:1.项目概述:介绍项目的背景、目的和重要性。
2.安装说明:列出项目的依赖和安装方式。
3.使用说明:详细介绍项目的使用方式和常见问题。
4.代码结构:描述项目的代码结构、模块划分、函数调用关系等。
5. API文档:如果项目提供API接口,需要详细描述每个接口的使用方法和参数说明。
6.示例代码:提供一些简单的示例代码,帮助读者更好地理解项目的功能和用法。
7.常见问题解答:列出一些常见问题及解决方法,便于读者在使用过程中遇到问题时进行参考。
四、文档内容的编写技巧在编写代码文档的过程中,我们还需要注意一些编写技巧,以确保文档的准确性和易读性。
1.使用简单明了的语言:尽量使用简单明了的语言,避免使用过于复杂的专业术语。
2.结合示例说明:在文档中尽量使用示例代码和图片来说明功能和使用方法,更容易引起读者的兴趣。
3.添加链接和跳转:在文档中添加链接和跳转,便于读者快速找到所需信息。
4.保持文档更新:随着项目的迭代和更新,文档也需要及时更新,保持与代码的同步。
5.避免过度描述:在文档中避免过度描述和冗长的叙述,尽量精简明了。
6.提供参考文档:在文档的末尾提供一些参考文档和资源,帮助读者深入了解和学习。
目录 1 编程风格....................................................................................................................................... 1 1.1 统一编程风格的意义 ........................................................................................................ 1 1.2 变量命名的规则 ................................................................................................................ 1 1.3 函数的命名规范 ................................................................................................................ 3 1.4 函数参数规范 .................................................................................................................... 3 1.5 引出函数规范 .................................................................................................................... 4 1.6注释规范 ............................................................................................................................. 4 2 代码组织....................................................................................................................................... 5 3 代码优化....................................................................................................................................... 6 3.1 代码优化的意义 ................................................................................................................ 6 3.2代码优化的方法 ................................................................................................................. 6 4 调试技巧....................................................................................................................................... 7 4.1静态检查 ............................................................................................................................. 7 4.2 上机调试 ............................................................................................................................ 7 4.3 C语言常见问题 ................................................................................................................. 8
1 编程风格 1.1 统一编程风格的意义 • 增加开发过程代码的强壮性、可读性、易维护性 • 减少有经验和无经验开发人员编程所需的脑力工作 • 为软件的良好维护性打下好的基础 • 在项目范围内统一代码风格 • 通过人为以及自动的方式对最终软件应用质量标准 • 使新的开发人员快速适应项目氛围 • 支持项目资源的复用:允许开发人员从一个项目区域(或子项目团队)移动到另一个,而不需要重新适应新的子项目团队的氛围 • 一个优秀而且职业化的开发团队所必需的素质
1.2 变量命名的规则 ①变量的命名规则要求用“匈牙利法则”。 即开头字母用变量的类型,其余部分用变量的英文意思或其英文意思的缩写,尽量避免用中文的拼音,要求单词的第一个字母应大写。 即: 变量名=变量类型+变量的英文意思(或缩写) 对非通用的变量,在定义时加入注释说明,变量定义尽量可能放在函数的开始处。 见下表: bool(BOOL) 用b开头 bIsParent byte(BYTE) 用by开头 byFlag short(int) 用n开头 nStepCount long(LONG) 用l开头 lSum char(CHAR) 用c开头 cCount float(FLOAT) 用f开头 fAvg double(DOUBLE) 用d开头 dDeta void(VOID) 用v开头 vVariant unsigned int(WORD) 用w开头 wCount unsigned long(DWORD) 用dw开头 dwBroad HANDLE(HINSTANCE) 用h开头 hHandle DWORD 用dw开头 dwWord LPCSTR(LPCTSTR) 用str开头 strString 用0结尾的字符串 用sz开头 szFileName
对未给出的变量类型要求提出并给出命名建议给技术委员会。 ②、指针变量命名的基本原则为: 对一重指针变量的基本原则为: “p”+变量类型前缀+命名 如一个float*型应该表示为pfStat 对多重指针变量的基本规则为: 二重指针: “pp”+变量类型前缀+命名 三重指针: “ppp”+变量类型前缀+命名 ③、全局变量用g_开头,如一个全局的长型变量定义为g_lFailCount,即:变量名=g_+变量类型+变量的英文意思(或缩写) ④、静态变量用s_开头,如一个静态的指针变量定义为s_plPerv_Inst,即: 变量名=s_+变量类型+变量的英文意思(或缩写) ⑤、成员变量用m_开头,如一个长型成员变量定义为m_lCount;即:变量名=m_+变量类型+变量的英文意思(或缩写) ⑥、对枚举类型(enum)中的变量,要求用枚举变量或其缩写做前缀。并且要求用大写。 如:enum cmEMDAYS { EMDAYS_MONDAY; EMDAYS_TUESDAY; …… }; ⑦、对struct、union、class变量的命名要求定义的类型用大写。并要加上前缀,其内部变量的命名规则与变量命名规则一致。 结构一般用S开头 如:struct ScmNPoint { int nX;//点的X位置 int nY; //点的Y位置 }; 联合体一般用U开头 如: union UcmLPoint { long lX; long lY; } 类一般用C开头 如: class CcmFPoint { public: float fPoint; }; 对一般的结构应该定义为类模板,为以后的扩展性考虑 如: template class CcmTVector3d { public: TYPE x,y,z; }; ⑧、对常量(包括错误的编码)命名,要求常量名用大写,常量名用英文表达其意思。 如:#define CM_FILE_NOT_FOUND CMMAKEHR(0X20B) 其中CM表示类别。 ⑨、对const 的变量要求在变量的命名规则前加入c_,即:c_+变量命名规则;例如: const char* c_szFileName;
1.3 函数的命名规范 函数的命名应该尽量用英文表达出函数完成的功能。遵循动宾结构的命名法则,函数名中动词在前,并在命名前加入函数的前缀,函数名的长度不得少于8个字母。 例如: long cmGetDeviceCount(……);
1.4 函数参数规范 ①、 参数名称的命名参照变量命名规范。 ②、 为了提高程序的运行效率,减少参数占用的堆栈,传递大结构的参数,一律采用指针或引用方式传递。 ③、 为了便于其他程序员识别某个指针参数是入口参数还是出口参数,同时便于编译器检查错误,应该在入口参数前加入const标志。如: …cmCopyString(const char * c_szSource, char * szDest)