C++深度系列：实战指南，挖掘ISO/ANSI C++标准精华

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

"C++ Coding Standards(英文版) 1st.pdf" 是一本专注于C++编程语言标准的专业书籍，由Bjarne Stroustrup编著，他是C++语言的创始人。这本书标志着C++编程进入了一个新时代，随着ISO/ANSI C++标准的发布，它提供了大量的新功能和可能性，但同时也带来了信息量巨大的挑战。对于实际开发中的程序员来说，如何在短时间内找到这些宝贵的知识点，提升编程技能显得尤为重要。《C++深度探索系列》正是为此而生。这个系列旨在通过深入、集中的指导，帮助程序员在特定主题上迅速学习和理解。每本书都针对其关注的主题，以技术层面的详尽阐述，确保内容专业且实用，避免了无关的干扰，让读者能够专注于提升自身技术能力。系列中的书籍相互引用，形成一个连贯的知识体系，并且与Bjarne Stroustrup的原著《C++编程语言》保持紧密联系。在C++编程的道路上，随着技术的发展，区分真正重要的信息和过度包装变得至关重要。《C++ Coding Standards(英文版) 1st.pdf》作为系列的一部分，不仅提供了关键知识点的提炼，还帮助读者在快速变化的技术海洋中定位并掌握核心要素，以适应职业发展的需求。通过阅读和参考这些短小精悍的专题论文，程序员可以有效地提升自己的专业素养，从而在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页未读，继续阅读

zhichizhongguo

粉丝: 14
资源: 88

C++深度系列：实战指南，挖掘ISO/ANSI C++标准精华

C++ Coding Standards,101 Rules,Guidelines and Best Practices

C++_Coding_Standards_101_Rule

CPP Coding Standards - 101 Rules Guidelines and Best Practices 2005.pdf

C++ Coding Standards

c++ Coding Standards

c++coding standards

C++ CODING STANDARDS

Symbian C++ Coding Standards

c++ coding standard 英文版

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

最新资源