C++编程规范：深入解析与实践指南

需积分: 10 183 浏览量更新于2024-07-26 收藏 1.25MB PDF 举报

"C++ Coding Standards(英文版) 1st.pdf" C++编程规范是C++程序员必须掌握的重要参考资料，由Bjarne Stroustrup编辑的《C++ Coding Standards》是深入系列的一部分，旨在帮助开发者在ISO/ANSI C++标准的海量信息中找到关键的编程智慧。该书的出现标志着C++进入了一个新的时代，因为标准引入了许多新的功能和机会，但同时也增加了学习的复杂性。 C++ In-Depth Series的目标是减少学习时间和混乱，为程序员提供针对特定主题的简洁、专注的指导。这个系列中的每一本书都专注于一个特定的技术主题，并且以与该主题相适应的技术级别进行阐述。这种实用的方法旨在帮助专业程序员提升他们的编程技能。专家编写的这些短篇、深入的专著可以独立阅读和参考，避免了无关材料的干扰。系列内各书相互交叉引用，并且会参考Bjarne Stroustrup的《C++ Programming Language》，这为读者提供了更全面的学习路径。随着您在C++领域的技能发展，区分核心信息与营销宣传变得至关重要。这个系列书籍帮助您建立良好的编码习惯，理解标准库的使用，以及如何有效地利用新特性来提高代码质量和可维护性。它涵盖了模板、异常处理、设计模式、内存管理、STL（标准模板库）以及面向对象和泛型编程的最佳实践。例如，书中可能会详细讨论模板元编程，这是一种在编译时执行计算的技术，可以用于创建高度优化的代码。此外，它可能还会深入探讨智能指针的使用，这是防止内存泄漏的关键工具。异常处理的章节将指导读者如何正确地处理程序中的错误情况，而不仅仅是避免错误，而是优雅地恢复和报告。 C++的面向对象特性，如继承、封装和多态，也会被详细解释，以帮助读者理解和实现可扩展和模块化的软件设计。同时，书中可能还包括对C++11及后续版本新增特性的介绍，如lambda表达式、右值引用和自动类型推断等，这些都是现代C++编程不可或缺的部分。《C++ Coding Standards》是提升C++编程能力的宝贵资源，它不仅提供技术指导，还强调了代码的可读性、可维护性和安全性。通过遵循这些标准，开发者能够编写出更高效、更可靠，同时易于团队合作的代码。

Organizational and

Policy Issues

If builders built buildings the way programmers wrote programs, then

the first woodpecker that came along would destroy civilization.

—Gerald Weinberg

In the grand tradition of C and C++, we count the zero-based way. The prime directive,

Item 0, covers what we feel is the most basic advice about coding standards.

The rest of this introductory section goes on to target a small number of carefully se-

lected basic issues that are mostly not directly about the code itself, but on essential

tools and techniques for writing solid code.

Our vote for the most valuable Item in this section goes to Item 0: Don't sweat the

small stuff. (Or: Know what not to standardize.)

C++ Coding Standards

0. Don't sweat the small stuff.

(Or: Know what not to standardize.)

Summary

Say only what needs saying: Don't enforce personal tastes or obsolete practices.

Discussion

Issues that are really just personal taste and don't affect correctness or readability

don't belong in a coding standard. Any professional programmer can easily read and

write code that is formatted a little differently than they're used to.

Do use consistent formatting within each source file or even each project, because it's

jarring to jump around among several styles in the same piece of code. But don't try to

enforce consistent formatting across multiple projects or across a company.

Here are several common issues where the important thing is not to set a rule but just

to be consistent with the style already in use within the file you're maintaining:

•

Don't specify how much to indent, but do indent to show structure: Use any number

of spaces you like to indent, but be consistent within at least each file.

•

Don't enforce a specific line length, but do keep line lengths readable: Use any length

of line you like, but don't be excessive. Studies show that up to ten-word text

widths are optimal for eye tracking.

•

Don't overlegislate naming, but do use a consistent naming convention: There are only

two must-dos: a) never use "underhanded names," ones that begin with an un

derscore or that contain a double underscore; and b) always use

ONLY_UPPERCASE_NAMES

for macros and never think about writing a macro

that is a common word or abbreviation (including common template parame

ters, such as T and U; writing

#define T

anything is extremely disruptive). Oth

erwise, do use consistent and meaningful names and follow a file's or module's

convention. (If you can't decide on your own naming convention, try this one:

Name classes, functions, and

enums LikeThis;

name variables

likeThis;

name

private member variables

likeThis_;

and name macros

LIKE_THIS.)

•

Don't prescribe commenting styles (except where tools extract certain styles into docu

mentation), but do write useful comments: Write code instead of comments where

possible (e.g., see Item 16). Don't write comments that repeat the code; they get

out of sync. Do write illuminating comments that explain approach and rationale.

Finally, don't try to enforce antiquated rules (see Examples 3 and 4) even if they once

appeared in older coding standards.

Examples

Example 1: Brace placement. There is no readability difference among:

Organizational and Policy Issues 3

void using_k_and_r_style() {

void putting_each_brace_on_its_own_line()

void or_putting_each_brace_onjts_own_line_indented()

Any professional programmer can easily read and write any of these styles without

hardship. But do be consistent: Don't just place braces randomly or in a way that ob-

scures scope nesting, and try to follow the style already in use in each file. In this

book, our brace placement choices are motivated by maximizing readability within

our editorial constraints.

Example 2: Spaces vs. tabs. Some teams legitimately choose to ban tabs (e.g.,

[BoostLRG]), on the grounds that tabs vary from editor to editor and, when mis-used,

turn indenting into outdenting and nondenting. Other equally respectable teams

legitimately allow tabs, adopting disciplines to avoid their potential draw-backs. Just

be consistent: If you do allow tabs, ensure it is never at the cost of code clarity and

readability as team members maintain each other's code (see Item 6). If you don't

allow tabs, allow editors to convert spaces to tabs when reading in a source file so

that users can work with tabs while in the editor, but ensure they con-vert the tabs

back to spaces when writing the file back out.

Example 3: Hungarian notation. Notations that incorporate type information in

vari-able names have mixed utility in type-unsafe languages (notably C), are possible

but have no benefits (only drawbacks) in object-oriented languages, and are

impossible in generic programming. Therefore, no C++ coding standard should

require Hun-garian notation, though a C++ coding standard might legitimately

choose to ban it.

Example 4: Single entry, single exit ("SESE"). Historically, some coding standards have

required that each function have exactly one exit, meaning one return statement.

Such a requirement is obsolete in languages that support exceptions and destructors,

where functions typically have numerous implicit exits. Instead, follow standards

like Item 5 that directly promote simpler and shorter functions that are inherently

easier to understand and to make error-safe.

References

[BoostLRG] • [Brooks95] §12 • [Constantine95] §29 • [Keffer95] p. 1 • [Kernighan99] §1.1,

§1.3, §1.6-7 • [Lakos96] §1.4.1, §2.7 • [McConnell93] §9, §19 • [Stroustrup94] §4.2-3 •

[StroustrupOO] §4.9.3, §6.4, §7.8, §C.l • [SutterOO] §6, §20 • [SuttHyslOl]

C++ Coding Standards

1. Compile cleanly at high warning levels.

Summary

Take warnings to heart: Use your compiler's highest warning level. Require clean

(warning-free) builds. Understand all warnings. Eliminate warnings by changing

your code, not by reducing the warning level.

Discussion

Your compiler is your friend. If it issues a warning for a certain construct, often

there's a potential problem in your code.

Successful builds should be silent (warning-free). If they aren't, you'll quickly get

into the habit of skimming the output, and you will miss real problems. (See Item 2.)

To get rid of a warning: a) understand it; and then b) rephrase your code to eliminate

the warning and make it clearer to both humans and compilers that the code does

what you intended.

Do this even when the program seemed to run correctly in the first place. Do this

even when you are positive that the warning is benign. Even benign warnings can

obscure later warnings pointing to real dangers.

Examples

Example 1: A third-party header file. A library header file that you cannot change could

contain a construct that causes (probably benign) warnings. Then wrap the file with

your own version that #includes the original header and selectively turns off the

noisy warnings for that scope only, and then #include your wrapper throughout the

rest of your project. Example (note that the warning control syntax will vary from

compiler to compiler):

//File: myproj/myjambda.h -- wraps Boost's lambda.hpp

// Always include this file; don't use lambda.hpp directly.

// NOTE: Our build now automatically checks "grep lambda.hpp <srcfile>".

// Boost.Lambda produces noisy compiler warnings that we know are innocuous.

// When they fix it we'll remove the pragmas below, but this header will still exist.

#pragma warning(push) //disable for this header only

#pragma warning(disable:4512)

#pragma warning(disable:4180)

#include <boost/lambda/lambda.hpp> #pragma

warning(pop) //restore original warning level

剩余224页未读，继续阅读

kobegod8

粉丝: 4
资源: 13

C++编程规范：深入解析与实践指南

c++ Coding Standards

C++编程规范-101条规则(C++ Coding Standards)中文版 part2

C++编程规范-101条规则(C++ Coding Standards)中文版 part1

C++ Coding Standards

c++coding standards

C++ CODING STANDARDS

Symbian C++ Coding Standards

c++ coding standard 英文版

[C++经典著作]C++ Coding Standards Guidelines

C++编程规范-101条规则(C++ Coding Standards)中文版 part3

最新资源