C++编程陷阱与避坑指南

5星 · 超过95%的资源需积分: 10 186 浏览量更新于2023-06-23 收藏 2.38MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

[ Team LiB ]

Gotcha #1: Excessive Commenting

Many comments are unnecessary. They generally make source code hard to read and maintain, and frequently lead

maintainers astray. Consider the following simple statement:

a = b; // assign b to a

The comment cannot communicate the meaning of the statement more clearly than the code itself, and so is useless.

Actually, it's worse than useless. It's deadly. First, the comment distracts the reader from the code, increasing the

volume of text the reader has to wade through in order to extract its meaning. Second, there is more source text to

maintain, since comments must be maintained as the program text they describe is modified. Third, this necessary

maintenance is often not performed.

c = b; // assign b to a

A careful maintainer cannot simply assume the comment is in error and is obliged to trace through the program to

determine whether the comment is erroneous, officious ( c is a reference to a ), or subtle (assigning to c will later cause

the same assignment to be propagated to a somehow). The line should originally have been written without a

comment:

a = b;

The code is maximally clear as it stands, with no comment to be incorrectly maintained. This is similar in spirit to the

well-worn observation that the most efficient code is code that doesn't exist. The same applies to comments: the best

comment is one that didn't have to be written, because the code it would otherwise have described is

self-documenting.

Other common examples of unnecessary comments frequently occur in class definitions, either as the result of an

ill-conceived coding standard or as the work of a C++ novice:

class C {

// Public Interface

public:

C(); // default constructor

~C(); // destructor

// . . .

};

You get the feeling you're reading someone's crib notes. If a maintainer has to be reminded of the meaning of the

public: label, you don't want that person maintaining your code. None of these comments does anything for an

experienced C++ programmer except clutter the code and provide more source text to be improperly maintained.

class C {

// Public Interface

protected:

C( int ); // default constructor

public:

virtual ~C(); // destructor

// . . .

};

Programmers also have a strong incentive not to "waste" lines of source text. Anecdotally, if a construct (function,

public interface of a class, and so on) can be presented in a conventional and rational format on a single "page" of

about 30-40 lines, it will be easy to understand. If it goes on to a second page, it will be about twice as hard to

understand. If it goes onto a third page, it will be approximately four times as hard to understand.

A particularly odious practice is that of inserting change logs as comments at the head or tail of source code files:

/* 6/17/02 SCD fixed the gaforniflat bug */

Is this useful information, or is the maintainer just bragging? This comment is unlikely to be of any use whatever

within a week or two of its insertion, but it will hang on grimly for years, distracting generations of maintainers. A

much better alternative is to cede these commenting tasks to your version control software; a C++ source code file is

no place to leave a laundry list.

One of the best ways to avoid comments and make code clear and maintainable is to follow a simple, well-defined

naming convention and choose clear names that reflect the abstract meaning of the entity (function, class, variable,

and so on) you're naming. Formal argument names in declarations are particularly important. Consider a function that

takes three arguments of identical type:

Perform the action from the source to the destination.

Arg1 is action code, arg2 is source, and arg3 is destination.

void perform( int, int, int );

Not too terrible, but think what it would look like with seven or eight arguments instead of three. We can do better:

void perform( int actionCode, int source, int destination );

Better, though we should probably still have a one-liner that tells us what the function does (though not how it does

it). One of the most attractive things about formal argument names in declarations is that they, unlike comments, are

generally maintained along with the rest of the code, even though they have no effect on the code's meaning. I can't

think of a single programmer who would switch the meanings of the second and third arguments of the perform

function without also changing their names, but I can identify legions of programmers who would make the change

without maintaining the comment.

Kathy Stark may have said it best in Programming in C++ : "If meaningful and mnemonic names are used in a

program, there is often only occasional need for additional comments. If meaningful names are not used, it is unlikely

that any added comments will make the code easy to understand."

Another way to minimize comments is to employ standard or well-known components:

printf( "Hello, World!" ); // print "Hello, World" to the screen

This comment is both useless and only occasionally correct. It's not that standard components are necessarily

Gotcha #2: Magic Numbers

Magic numbers, in the sense used here, are raw numeric literals used in contexts where named constants should be

used instead:

class Portfolio {

// . . .

Contract *contracts_[10];

char id_[10];

};

The main problem with magic numbers is that they have no semantic content to speak of; they are what they are. A

10 is a 10 , not a maximum number of contracts or the length of an identifier. Therefore we're obliged, when reading or

maintaining code that employs magic numbers, to determine the intended meaning of each raw literal. That's work,

and it's unnecessary and often inaccurate work.

For example, our poorly designed portfolio above can manage a maximum of ten contracts. That's not a lot of

contracts, so we may decide to increase it to 32. (If we had any concern about safety and correctness, we'd use a

standard vector .) The trouble is that we're now obliged to examine every source file that uses Portfolio for each

occurrence of the literal 10 , to decide if that 10 means maximum number of contracts.

Actually, the situation can be worse. In large and long-lived projects, sometimes word gets out that the maximum

number of contracts is ten, and this knowledge becomes embedded in code that doesn't even indirectly include the

Portfolio header file:

for( int i = 0; i < 10; ++i )

// . . .

Does this literal 10 refer to the maximum number of contracts? The length of an identifier? Something unrelated?

The chance confluence of raw literals can sometimes bring out the worst coding tendencies in programmers:

if( Portfolio *p = getPortfolio() )

for( int i = 0; i < 10; ++i )

p->contracts_[i] = 0, p->id_[i] = '\0';

Now the maintainer has to somehow tease apart the initializations of the different components of a Portfolio that

would not have been combined but for the chance coincidence of the values of two distinct concepts. There is really

no excuse for provoking all this complexity when the solution is so simple:

class Portfolio {

// . . .

enum { maxContracts = 10, idlen = 10 };

Contract *contracts_[maxContracts];

char id_[idlen];

};

Enumerators consume no space and cost nothing in runtime while providing clear, properly scoped names of the

concepts for which they stand.

剩余314页未读，继续阅读

  
 小李龙
 
              粉丝: 0
            
 资源: 6
 
  
      上传资源 快速赚钱
    
  我的内容管理 
          收起
          
   我的资源 
              快来上传第一个资源
              
   我的收益  登录查看自己的收益 
  我的积分 
              登录查看自己的积分
              
  我的C币 
              登录后查看C币余额
             
   我的收藏 
  我的下载  
   下载帮助  
  
 会员权益专享
  图片转文字 PDF转文字 PDF转Word PDF加水印
 全年可省5，000元立即开通
  最新资源
 
        构建智慧路灯大数据平台：物联网与节能解决方案
      

        智慧开发区建设：探索创新解决方案
      

        SQL查询实践：员工、商品与销售数据分析
      

        2022智慧酒店解决方案：提升服务效率与体验
      

        2022年智慧景区信息化整体解决方案：打造数字化旅游新时代
      

        2022智慧景区建设：大数据驱动的5A级管理与服务升级
      

        2022智慧教育综合方案：迈向2.0时代的创新路径与实施策略
      

        2022智慧教育：构建区域教育云，赋能学习新时代
      

        2022智慧教室解决方案：融合技术提升教学新时代
      

        构建智慧机场：2022年全面信息化解决方案
      

        2022智慧机场建设：大数据与物联网引领的生态转型与客户体验升级
      

        智慧机场2022安防解决方案：打造高效指挥与全面监控系统
      

        2022智慧化工园区一体化管理与运营解决方案
      

        2022智慧河长管理系统：科技助力水环境治理
      

        伪随机相位编码雷达仿真及FFT增益分析
      

        2022智慧管廊建设：工业化与智能化解决方案
      
  
 资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！ 
      点击此处反馈

          
 
 安全验证
 文档复制为VIP权益，开通VIP直接复制
  信息提交成功

C++编程陷阱与避坑指南

vc编程系列之Addison Wesley - C++ Gotchas

[AddisonWesley]C++_Gotchas.zip

MindeNLP+MusicGen-音频提示生成

WNM2027-VB一款SOT23封装N-Channel场效应MOS管

线上营销推广策略设计与效果评估研究

钢铁集团智慧工厂信息化建设解决方案两份文档.pptx

2024年投资策略-AIGC海阔凭鱼跃，数据要素破浪会有时.pdf

2023中国文化产业和旅游业年度盘点报告（2022）-北京京和文旅发展研究院.pdf

英锐恩电子烟相关芯片推荐

2024年东南亚断续器市场深度研究及预测报告.pdf

ElasticSearch.pdf

智慧农牧业解决方案两份文件.pptx

Object-C语言教程&案例.md

2023中国制造业的可持续生存之道-中国企业ESG实践调研问卷分析报告-IMA(1).pdf

Brand Finance：2023年银行业500强(1).pdf

会员权益专享

最新资源

C++编程陷阱与避坑指南

[CS]C++ Gotchas

C++ Gotchas .chm

C++ gotchas（c++覆辙录英文版）

verilog and systemverilog gotchas电子书

vc编程系列之Addison Wesley - C++ Gotchas

[AddisonWesley]C++_Gotchas.zip

MindeNLP+MusicGen-音频提示生成

WNM2027-VB一款SOT23封装N-Channel场效应MOS管

线上营销推广策略设计与效果评估研究

钢铁集团智慧工厂信息化建设解决方案两份文档.pptx

2024年投资策略-AIGC海阔凭鱼跃，数据要素破浪会有时.pdf

2023中国文化产业和旅游业年度盘点报告（2022）-北京京和文旅发展研究院.pdf

英锐恩电子烟相关芯片推荐

2024年东南亚断续器市场深度研究及预测报告.pdf

ElasticSearch.pdf

智慧农牧业解决方案两份文件.pptx

Object-C语言教程&案例.md

2023中国制造业的可持续生存之道-中国企业ESG实践调研问卷分析报告-IMA(1).pdf

Brand Finance：2023年银行业500强(1).pdf

会员权益专享

最新资源