首页 > 编程知识 正文

华为编程规范试题,华为安全编程规范考试

时间:2023-05-05 01:00:44 阅读:19918 作者:121

1、引言是衡量代码自身缺陷的标准,也是衡量研发人员自身价值的标准。 作为一家全球化的IT公司,华为有十几万名员工,无论是人力资源管理,还是代码管理,都不容易。 没有规范的约束,想想都是可怕的。 现在,我们来挑选几个网络上出现的编程规范,一起学习吧。 以下内容与基础语法规范无关,为了提高程序的健壮性、可维护性等,重点讨论了一些编程习惯。

2、军规简介军规一:“程序中不要使用恶魔数字,必须用有意义的常量标识。 】

军规二【明确方法功能,一种方法只完成一种功能。 】

军规三【方法参数不得超过5个】

军规四【方法调用不返回null,而是抛出异常,或者代替以特殊对象集合或数组类型为返回值的方法】

军规五【进行数据库操作和IO操作,必须确保资源使用完毕后释放,确保释放操作在finally上进行。 】

军规六【异常捕获不要直接catch(exceptionex ),异常应细化处理。 】

关于军规七【ifelse (后续可能有多个elseif)这一类型的条件判断,最后包括一个else分支在内,需要避免分支遗漏造成的错误。 必须确保每个switch-case语句都有default,以免发生分支泄漏而发生错误。 】

军规八【瞄准写入对象的equals ()方法时,也必须同时写入hashCode ) )方法。 】

军规九【禁止在循环中创建新线程,尽量使用线程池。 】

(军规十)在精确计算(例如:货币计算)中,请避免使用浮点和双精度。 浮点计算不准确,因此必须使用BigDecimal或将浮点运算转换为整数运算。 】

3、军规说明军规一:“不要在程序中使用恶魔数字,要用有意义的常量标识。 】说明:是否是恶魔的数字,是基于容易阅读、容易全局置换的原则。 0、1列举数值作为某一专业领域的物理量时,必须定义常数,严禁NUMBER_ZERO这样的“恶魔常数”。

军规二【明确方法功能,一种方法只完成一种功能。 】说明:方法功能过多会增加方法的复杂性和依赖关系,不利于程序的读取和未来的持续维护。 无论是方法还是类设计都必须遵循单一责任原则。

军规三:“方法参数不能超过5个”说明:参数过多影响代码的阅读和使用。 为了减少参数,首先考虑这些参数的合理性,保持方法的单一功能,优化方法设计。 如果参数确实不减少,考虑到将多个参数封装在一个类(对象)中并同时向新的类(对象)添加适当的动作,期望更匹配OOP。

军规四【方法调用不返回null,而是抛出异常,或者代替以特殊对象集合或数组类型为返回值的方法】说明:返回null会增加对不需要的null指针的判断,如果判断错误,可能会导致严重的NullPointerException错误。

军规五【进行数据库操作和IO操作,必须确保资源使用完毕后释放,确保释放操作在finally上进行。 】说明:数据库操作、IO操作等需要关闭的对象在try -catch-finally的finally中为close (),如果需要关闭多个IO对象,则为每个对象的close (),"

军规六【异常捕获不要直接catch(exceptionex ),异常应细化处理。 】说明: catch(exceptionex )的结果可捕捉运行时执行的异常。 RuntimeException是运行时异常,是程序自身思考不够而抛出的异常,是程序错误,必须防止程序抛出,如无效参数、数组越界、除零等

军规七【关于ifelseif (后续可能有多个elseif)这一类型的条件判断,最后包括一个else分支在内,需要避免分支遗漏造成的错误。 必须确保每个switch-case语句都有default,以免发生分支泄漏而发生错误。 】

军规八【瞄准写入对象的equals ()方法时,也必须同时写入hashCode ) )方法。 】说明: equals和hashCode方法是对象在hash容器中高效运行的基础,正确描述这两种方法,保证了对象在hash容器中搜索的正确性,同时也是一种很好的hashCode方法

军规九【禁止在循环中创建新线程,尽量使用线程池。 】

(军规十)在精确计算(例如:货币计算)中,请避免使用浮点和双精度。 浮点计算不准确,因此必须使用BigDecimal或将浮点运算转换为整数运算。 】说明:浮点运算在大范围值域提供了很好的逼近,但不能给出准确的结果。 二进制浮点非常不适用于精度计算,因为它不能准确表示0.1——或10的其他负幂

为一个长度有限的二进制小数。

具体案例请参考:浮点数加法引发的问题:浮点数的二进制表示

4、有关开发效率和协作的几点建议与心得体会

今天看到某同学写给团队成员的一封邮件,发现比较通用,分享出来吧:

1、小提交:

把大的任务拆分成多个独立小任务,每完成小任务确保无 Bug 后就可以提交合并到主分支甚至发布;频繁提交有利于自己把控项目进度、降低风险、同其他人协作和代码 Review ; 每天可以提交合并多次。每个小任务是 1-2 个小时可以完成的粒度,最大的一天完成。并行做多个任务的时候,优先做最短时间能够实现的任务。

2、命名规范:

尽量避免无意义的字符做变量 比如 a, b, t 。可以逐步改善,可以参考:http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

3、避免过度设计: 能够用简单方式实现的功能,不引入复杂的类,对象,避免不必要的 new 对象,避免引入不必要的泛型、线程。开发初期冗余大于抽象和依赖。避免自己重新实现比较通用的组件和函数。调研多种实现方式的时候,选用做简单的实现方式。尽量少写代码。

4、Web 工程尽量避免在应用内部保存“状态”,这样可以适应频繁发布、重启无影响。

5、善于用打日志的方式调试,在程序关键点打日志。尽量少用断点方式,日志方式可以批量调试一批功能,效率相对高。

6、避免一屏显示不下的超大函数。

7、添加必要、简洁的注释:

循环中的 continue, break 尽量加上单行注释;尽量避免非函数结尾的 return,必要的时候加注释。类自动生成 toString() 方法,方便调试和打日志。

8、不把自己局限到做某个功能,每个人都是整个项目的 Owner ,尽量交叉 Review ,交叉开发。

9、遇到问题及时和其他人沟通,避免浪费时间。

10、从最终产品的目标审视自己细小的设计,熟悉自己负责部分的上下游代码。时刻关注最终产品(Web 界面和日志),发现 Bug 和可以改善的地方

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。