[OOD-More C++ Idioms] 写时拷贝 (Copy on Write)

本惯用法的目的是达到延迟拷贝(lazy copy)的优化目的。和延迟初始化(lazy initialization)相似, 选择在恰当的时机更加有效。...
阅读(1680) 评论(3)

表驱动法应用的难点

表驱动法就是两个过程: i. 提取共性,做到为每个元素做一样的事。把共性放到表中, 用查表法取代switch。 ii. 提供支持函数,因为提取共性后会要求有为这些共性服务的函数。第1步是比较简单的,把第2步想透了才会提升使用表驱动法的层次。...
阅读(3098) 评论(0)

代码大全之内训资料

分享两个在PRIMAX分享的PPT, 原件放在SlideShare上, CSDN不支持iFrame,只能用链接了。两个PPT分别是代码大全和程序员实践的内容。...
阅读(1686) 评论(0)

代码管理要责任到位

为什么我们在考虑代码管理的时候会担心影响程序员的积极性?精英化的团队是不是能完全解决代码质量的问题? 战功文化会引入什么样的代码管理问题? 以下是我对这些问题的思考。 代码之于程序员,就像沙场之于将军。普遍希望完全控制代码,可以自由驰聘、攻城掠地。但对于一个团队合作下的代码,这种行为却隐藏着极大的风险。特别是在一个崇尚战功文化的团队里,在鼓励大家承担更多责任的同时,同时也要注重对代码上的...
阅读(2094) 评论(1)

C++中的static变量

虽然是老生常谈,但下面这篇文章还是概括地很全面的。 C++中的static有以下三种不同的效果: 当用于成员变量时,表示它将由类分配管理而不是实例。 当在一个函数中时,数据将会被静态分配,在函数第一次被调用时初始化,且一直存在到程序退出。它当然也仅在当前函数中可用。这个特性经常被用于单例的延迟建构。  当在一个编译单元中(如源文件),它可以在本单元中视为全局的,但对...
阅读(1284) 评论(1)

关于代码布局(Coding Layout)

研究发现,缩进可以提高程序员的理解能力(Program Indentation and Comprehensibility>>, Miaria et al. 1983)。缩进是代码布局的一项技术。作为代码布局并不像命名和注释那样明确,它更像一种感觉。比如摄影的构图,或者国画的留白。虽然很难给一个标准的评价标准,但是>的作者Steve.McConnell和>的两位作者还是给了一些建议。   首先...
阅读(1748) 评论(0)

编码工艺Coding Techniques)-命名和注释

转载请注明出处:http://blog.csdn.net/horkychen (节选自MSDN-Coding Techniques and Programming Practices) 命名 (Names) 命名最有利于了解程序的逻辑结构。一个名字说明是"什么(what)”比说明"如何(how)"更重要。通过命名可以避免暴露底层的实现,从而保留一个抽象层,简化了程序的复杂性。例如,你可以...
阅读(2370) 评论(0)

[CodeComplete]创建一个函数需要理由吗

以下为代码大全2>>[第七章高质量的子程序]的摘录 编程中什么是标准,相信大家都没有办法给出一套成系统的理论,而《代码大全》的作者就是在为我们描述从设计到实现诸多大家或意识到而没有深究,又或者还没有意识到的问题,通过系统的方式为大家展开了软件开发中诸多细节。希望对大家能都所帮助! 本章探讨了以下问题:    创建子程序的正当理由    在子程序层上展开设计    起个好名字...
阅读(2244) 评论(0)

数组的误用

原文地址: Teaching C++ Badly: How to Misuse Arrays   我上次写了篇文章列举了我所看到的一些不好的C++教学,并且承诺详细地解释这些技术。这篇就是其中的第一篇。 我见到有归因于Trenchard More(*定义了More Array Theory)的断言,说数组是所有数据结构中最基本的一个。 事实上几乎没有哪个在世的程序员没有使用过数组。如果没有足够...
阅读(1062) 评论(0)

《代码整洁之道》摘录---格式

团队应该一致同意采用一套简单的格式规则,可以运用将这些规则自动化的工具。 代码格式关乎沟通,而沟通是专业开发者的头等大事。 或许你认为“让代码能工作”才是专业开发者的第一优先级。你今天编写的功能,极有可能在下一版本中被修改,但代码的可读性却会对以后可能发生的修改行为产生深远影响。原始代码修改之后很久,其代码风格和可读性仍会影响到可维护性和扩展性。即便代码已不复存在,你的风格和律条仍存活...
阅读(1678) 评论(0)

《代码整洁之道》摘录---注释

注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。我们总无法找到不用注释就能表达自我的方法,所以总要有注释,这并不值庆贺。   如果你发现自己需要写注释,再想想看是否有办法翻盘,用代码来表达。   注释会撒谎。注释存在的时间越久,就离其所描述的代码越远,可能变得全然错误。原因很简单:程序员不能坚持维护注释。   程序员应当负责将注释保持在可维护、有关联、精确的高度。我同意这种说法。...
阅读(1710) 评论(0)
    个人资料
    • 访问:1471264次
    • 积分:16338
    • 等级:
    • 排名:第606名
    • 原创:217篇
    • 转载:29篇
    • 译文:46篇
    • 评论:361条
    微博/MSN/EMail

    新浪微博:Horky
    QQ:324014340
    Mail:horky.chen@gmail.com
    微信公众号 (聚焦软件开发):
    博客专栏
    最新评论