高质量编写c c++ 读书笔记（精选5篇）

第一篇：高质量编写c c++ 读书笔记

质量属性:正确性、健壮性、可靠性、效率、易用性、可读性（可理解性）、可扩展性、可复用性、兼容性、可移植

头文件:ifndef/define/endif

头文件的作用:

*通过头文件来调用库功能。在很多场合，源代码不便（或不准）向用户公布，只要向用户提供头文件和二进制的库即可。用户只需要按照头文件中的接口声明来调用库功能，而不必关心接口怎么实现的。编译器会从库中提取相应的代码。

*头文件能加强类型安全检查。如果某个接口被实现或被使用时，其方式与头文件中的声明不一致，编译器就会指出错误，这一简单的规则能大大减轻程序员调试、改错的负担。

如果一个软件的头文件数目比较多（如超过十个），通常应将头文件和 定义文件分别保存于不同的目录，以便于维护。

程序的板式:

程序的版式追求清晰、美观

在每个类声明之后、每个函数定义结束之后都要加空行。

一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释。

长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要进行适当的缩进，使排版整齐，语句可读。

命名规则:

*标识符最好采用英文单词或其组合，便于记忆和阅读。切忌使用汉语拼音来命名。

*命名规则尽量与所采用的操作系统或开发工具的风格保持一致。

*程序中不要出现仅靠大小写区分的相似的标识符。

*变量的名字应当使用“名词”或者“形容词＋名词”。

*全局函数的名字应当使用“动词”或者“动词＋名词”（动宾词组）。类的成员函数应当只使用“动词”，被省略掉的名词就是对象本身。

类名和函数名用大写字母开头的单词组合而成。

变量和参数用小写字母开头的单词组合而成。

常量全用大写的字母，用下划线分割单词。

静态变量加前缀 s_。

如果不得已需要全局变量，则使全局变量加前缀 g_（表示 global）。

类的数据成员加前缀 m_（表示 member），这样可以避免数据成员与成员函数的参数同名。

为了防止某一软件库中的一些标识符和其它软件库中的冲突，可以为各种标识符加上能反映软件性质的前缀。例如三维图形标准 OpenGL 的所有库函数 均以 gl 开头，所有常量（或宏定义）均以 GL 开头。

常量:

在 C++ 程序中只使用 const 常量而不使用宏常量，即 const 常量完全取代宏常量。

需要对外公开的常量放在头文件中，不需要对外公开的常量放在定义文件的头部。

建立在整个类中都恒定的常量应该用类中的枚举常量来实现。(只能是整数)

函数设计:

值传递（pass by value）

指针传递（pass by pointer）

引用传递（pass by reference）

目的参数放在前面，源参数放在后面。

如: char *strcpy(char *strDestination, const char *strSource);

第二篇：如何编写高质量“软件需求说明书”.doc

如何编写高质量“软件需求说明书”2003-01-27· · ··天极论坛 2 下一页

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。

现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪一个？需求24非常含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只因为你们对 其各有各的理解；并且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你要做大量的重复工作。

许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其 他原因是公司不愿意将其产品说明书放在公共区域。

这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好 的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。

高质量需求叙述的特性

我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试 例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。

正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。

只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。

可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。

必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑 必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。

优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优 先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时，项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

我是用3种级别的优先权：高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优先权表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。

明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS 作者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部 分预期的特性。

可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不 是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。

高质量需求说明的特征

一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。

一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。

可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。

可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。

需求质量的评审

这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个 从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢 迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。

例1．“产品应在不少于每60秒的正常周期内提供状态信息”

这个需求是不完整的：状态信息是什么，如何显示给用户。这个需 求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超 过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

弥补缺陷，重写需求的一种方法：

1、状态信息

1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息

1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比

1．3任务完成时，应显示相关的信息

1．4后台任务出错应该显示错误信息

为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性 表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可 打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没

有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不 会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全 体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/

将 要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主 官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档 不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，编写质量需求的方针

编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你 是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。

第三篇：如何编写高质量的“软件需求说明书”

如何编写高质量“软件需求说明书”

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。

现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪一个？需求24非常含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只因为你们对其各有各的理解；并且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你要做大量的重复工作。

许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其他原因是公司不愿意将其产品说明书放在公共区域。

这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。

高质量需求叙述的特性

我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。

正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。

只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。

可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。

必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。

优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时，项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

我是用3种级别的优先权：高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优先权表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。

明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。

可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。

高质量需求说明的特征

一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。

一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。

可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。

可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。

需求质量的评审

这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。

例1．“产品应在不少于每60秒的正常周期内提供状态信息”

这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

弥补缺陷，重写需求的一种方法：

1、状态信息

1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息

1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比

1．3任务完成时，应显示相关的信息

1．4后台任务出错应该显示错误信息

为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没

有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，编写质量需求的方针

编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。

第四篇：CC++的一些面试基本题

标题: C/C++的一些面试基本题

发信站: 兵马俑BBS(Wed Jun 16 15:00:14 2010), 本站(bbs.xjtu.edu.cn)

下面是自己面试时或是听别人说的一些C/C++面试基本题，都是语言细节和一些基本功，准备找工作的同学是可以看看。至于算法方面的，我面试过的公司都没有问什么有深度的东西（总是问我排序，堆栈方面的）。关于算法，我个人推荐一本书，algorithms in c（C算法）,我觉得这本书写的很好，很值得看（我现在就在看），如果能掌握了这本书的话，面试算法问题就不大了。我知道很多人更喜欢Introduction to algorithms(算法导论）这本书，这本书我买了一年多，惭愧，看了一半都不到，习题写得代码也不多。不过我个人更喜欢algorithms in c这本书，感觉它更适合我。

下面就是那些题目了，答案基本上我检验过，应该错误不多。

1.求下面函数的返回值（腾讯，阿里巴巴今年笔试都有）

int func(int x){

int countx = 0;

while(x){

countx++;

x = x &(xb))/ 2

13.如何打印出当前源文件的文件名以及源文件的当前行号？

答案：

cout << __FILE__;

cout<<__LINE__;

__FILE__和__LINE__是系统预定义宏，这种宏并不是在某个文件中定义的，而是由编译器定义的。

14.main 主函数执行完毕后，是否可能会再执行一段代码，给出说明？

答案：可以，可以用_onexit 注册一个函数，它会在main 之后执行。

15.如何判断一段程序是由C 编译程序还是由C++编译程序编译的？

答案：

#ifdef __cplusplus

cout<<“c++”;

#else

cout<<“c”;

#endif

16.下面程序的输出结果是什么啊?

#define SQR(X)X*X

int main(int argc, char* argv[]){

int a = 10;

int k = 2;

int m = 1;

a /= SQR(k+m)/SQR(k+m);

printf(“%dn”,a);

return 0;

}

答案： 1

17，const在一个函数中的4个位置的不同用法（面试我时我没有答上这个题，汗）主要是要理解const函数，不能改变对象。否则编译会报错。

18.写出运行结果:

union V {

struct X {

unsigned char s1:2;

unsigned char s2:3;

unsigned char s3:3;

} x;

unsigned char c;

} v;

v.c = 100;

printf(“%d”, v.x.s2);

}

答案： 1

19.用C++写个程序，如何判断一个操作系统是16位还是32位的？不能用sizeof()函数 A1:

16位的系统下，int i = 65536;

cout << i;// 输出0；

int i = 65535;

cout << i;// 输出-1；

32位的系统下，int i = 65536;

cout << i;// 输出65536；

int i = 65535;

cout << i;// 输出65535；

A2:

int a = ~0;

if(a>65536){

cout<<“32 bit”<

}

else{

cout<<“16 bit”<

}

20.在不用第三方参数的情况下，交换两个参数的值

方法1：

i=i+j;

j=i-j;

i=i-j;

方法二：

i^=j;

j^=i;

i^=j;

方法三：

// 用加减实现，而且不会溢出

a = a+b-(b=a)

21.写出输出结果

typedef union {

int a_int1;

double a_double;

int a_int2;

} a;

typedef struct {

a a1;

char y;

} b;

struct {

double c_double;

b b1;

a a2;

} c;

printf(“%dn”, sizeof(c));

答：有人说在VC下答案是32，我是linux系统，没法测试VC，但我知道在gcc下32位机默认的对齐是4（#pragma pack(4)），所以答案是28.22.试编写函数判断计算机的字节存储顺序是开序(little endian)还是降序(bigendian)答:

bool IsBigendian(){

unsigned short usData = 0x1122;

unsigned char*pucData =(unsigned char*)&usData;

return(*pucData == 0x22);

}

23.int id[sizeof(unsigned long)];这个对吗？为什么??

答:对，这个 sizeof是编译时运算符，编译时就确定了，可以看成和机器有关的常量。

24.找错

void test1(){

char string[10];

char* str1 = “0123456789”;

strcpy(string, str1);

}

答：数组越界。

25.分别给出bool，int，float，指针变量 与“零值”比较的 if 语句（假设变量名为var）答案：

bool型变量：if(!var)

int型变量： if(var==0)

float型变量：

const float EPSINON = 0.00001;

if((x >=-EPSINON)&&(x <= EPSINON)

指针变量：if(var==NULL)

26.请写一个C函数，若处理器是Big_endian的，则返回0;若是Little_endian的，则返回1 答：和22题一样，不过这里是另外一个方法。

nt checkCPU()

{

{

union w

{

int a;

char b;

} c;

c.a = 1;

return(c.b == 1);

}

}

27.多态类中的虚函数表是Compile-Time，还是Run-Time时建立的（此题我没有答上）? 答：是在编译时建立的。但在运行时刻才能知道究竟事调用那个函数。

28.写一个函数，判断一个int型的整数是否是2的幂，即是否可以表示成2^X的形式（不可以用循环）

bool IsTwoPower(int s){

return(s > 0)&&((s &(s-1))==0);//如果是2的幂的话，在二进制表示中只能有1个1 }

第五篇：黑马程序员C语言教程： CC++培训专家-编写高效C语言的四大绝招

传智播客C/C++培训专家：编写高效C语言的四大绝招

C语言是很多程序猿的入门语言，而且C语言也是一门用不过时的语言。编写高效简洁的C语言代码，是许多软件工程师追求的目标。今天传智播客C/C++培训专家针对编程工作中的一些体会和经验给大家做相关的阐述。

第一招：以空间换时间

计算机程序中最大的矛盾是空间和时间的矛盾，那么，从这个角度出发逆向思维来考虑程序的效率问题，我们就有了解决问题的第1招--以空间换时间。比如说字符串的赋值： 方法A：通常的办法 #define LEN 32 char string1 [LEN];memset(string1, 0, LEN);strcpy(string1, “This is a example！”);方法B：

const char string2[LEN] =“This is a example!”;char * cp;cp = string2;

从上面的例子可以看出，A和B的效率是不能比的。在同样的存储空间下，B直接使用指针就可以操作了，而A需要调用两个字符函数才能完成。B的缺点在于灵活性没有A好。在需要频繁更改一个字符串内容的时候，A具有更好的灵活性；如果采用方法B，则需要预存许多字符串，虽然占用了大量的内存，但是获得了程序执行的高效率。

第二招：数学方法解决问题

现在我们演绎高效C语言编写的第二招--采用数学方法来解决问题。数学是计算机之母，没有数学的依据和基础，就没有计算机的发展，所以在编写程序的时候，采用一些数学方法会对程序的执行效率有数量级的提高。举例如下，求 1~100的和。方法C： int I , j;for(I = 1;I<=100;I ++）{ j += I;} 方法D int I;I =(100 *(1+100))/ 2；

这个例子是我印象最深的一个数学用例，是我的计算机启蒙老师考我的。当时我只有小学三年级，可惜我当时不知道用公式 N×（N+1）

/ 2 来解决这个问题。方法E循环了100次才解决问题，也就是说最少用了100个赋值，100个判断，200个加法（I和j）；而方法F仅仅用了1个加法，1 次乘法，1次除法。效果自然不言而喻。所以，现在我在编程序的时候，更多的是动脑筋找规律，最大限度地发挥数学的威力来提高程序运行的效率。

第三招：使用位操作

实现高效的C语言编写的第三招——使用位操作。减少除法和取模的运算。在计算机程序中数据的位是可以操作的最小数据单位，理论上可以用“位运算”来完成所有的运算和操作。一般的位操作是用来控制硬件的，或者做数据变换使用，但是，灵活的位操作可以有效地提高程序运行的效率。举例如下： 方法E int I,J;I = 257 /8;J = 456 % 32;方法F int I,J;I = 257 >>3;J = 456-(456 >> 4 << 4);在字面上好像F比E麻烦了好多，但是，仔细查看产生的汇编代码就会明白，方法E调用了基本的取模函数和除法函数，既有函数调用，还有很多汇编代码和寄存器参与运算；而方法F则仅仅是几句相关的汇编，代码更简洁，效率更高。当然，由于编译器的不同，可能效率的差距不大，但是，以我目前遇到的MS C ,ARM C 来看，效率的差距还是不小。相关汇编代码就不在这里列举了。

运用这招需要注意的是，因为CPU的不同而产生的问题。比如说，在PC上用这招编写的程序，并在PC上调试通过，在移植到一个16位机平台上的时候，可能会产生代码隐患。所以只有在一定技术进阶的基础下才可以使用这招。用移位实现乘除法运算

a=a*4;

b=b/4;

可以改为：

a=a<<2;

b=b>>2;

说明：

除2 = 右移1位 乘2 = 左移1位

除4 = 右移2位 乘4 = 左移2位

除8 = 右移3位 乘8 = 左移3位

......通常如果需要乘以或除以2的n次方，都可以用移位的方法代替。大部分的C编译器,用移位的方法得到代码比调用乘除法子程序生成的代码效率高。

第四招：汇编嵌入

高效C语言编程的必杀技，第四招——嵌入汇编。“在熟悉汇编语言的人眼里，C语言编写的程序都是垃圾”。这种说法虽然偏激了一些，但是却有它的道理。汇编语言是效率最高的计算机语言，但是，不可能靠着它来写一个操作系统吧?所以，为了获得程序的高效率，我们只好采用变通的方法--嵌入汇编，混合编程。举例如下，将数组一赋值给数组二,要求每一字节都相符。char string1[1024],string2[1024];方法G int i;for(i =0;i<1024;i++)*(string2 + i)= *(string1 + i)方法H #ifdef _PC_ int I;for(I =0;I<1024;I++)*(string2 + I)= *(string1 + I);#else #ifdef _ARM_ __asm

{ MOV R0,string1 MOV R1,string2 MOV R2,#0 loop: LDMIA R0!, [R3-R11] STMIA R1!, [R3-R11] ADD R2,R2,#8 CMP R2, #400 BNE loop } #endif 方法G是最常见的方法，使用了1024次循环；方法H则根据平台不同做了区分，在ARM平台下，用嵌入汇编仅用128次循环就完成了同样的操作。这里有朋友会说，为什么不用标准的内存拷贝函数呢?这是因为在源数据里可能含有数据为0的字节，这样的话，标准库函数会提前结束而不会完成我们要求的操作。这个例程典型应用于LCD数据的拷贝过程。根据不同的CPU，熟练使用相应的嵌入汇编，可以大大提高程序执行的效率。

虽然是必杀技，但是如果轻易使用会付出惨重的代价。这是因为，使用了嵌入汇编，便限制了程序的可移植性，使程序在不同平台移植的过程中，卧虎藏龙，险象环生！同时该招数也与现代软件工程的思想相违背，只有在迫不得已的情况下才可以采用。

今天分享到这里，大家有遇到什么问题可以向“传智播客C/C++培训专家”留言哦！