IT牛人博客聚合

我们有很多Coding Style 或 代码规范。但这一条可能会经常被我们所遗忘，就是我们经常会在函数的参数里使用bool参数，这会大大地降低代码的可读性。不信？我们先来看看下面的代码。

当你读到下面的代码，你会觉得这个代码是什么意思？

widget->repaint(false);

是不要repaint吗？还是别的什么意思？看了文档后，我们才知道这个参数是immediate， 也就是说，false代表不立即重画，true代码立即重画。

Windows API中也有这样一个函数：InvalidateRect，当你看到下面的代码，你会觉得是什么意思？

InvalidateRect(hwnd, lpRect,  fals

查看全文: http://www.udpwork.com/item/5763.html

你曾去想重构一个很老的模块，但是你只看了一眼你就恶心极了。文档，奇怪的函数和类的命名，等等，整个模块就像一个带着脚镣的衣衫褴褛的人，虽然能走，但是其已经让人感到很不舒服。面对这种情况，真正的程序员会是不会认输的，他们会接受挑战认真分析，那怕重写也在所不惜。最终那个模块会被他们重构，就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样。下面是重构代码的几个阶段，文章来自：The 7 stages of refactoring，下面的翻译只是意译。

第一阶段 - 绝望

在你开始去查看你想要重构的模块的，你会觉得好像很简单，这里需要改一个类，那里需要改两到三个函数，重写几个函数，看上去没什么大不了的，一两天就搞定了。于是你着

查看全文: http://www.udpwork.com/item/5653.html

你是否相信如果你的程序里没有检查一个变量会导致怎么系统瘫痪？无论你相不相信，这是我一个亲身经历过的案例，你可以在本站的程序员那些悲催的事儿中找到很多这样的事。这样的事昨天在发生，今天同样在发生。Unix40多年了，在这40年里，程序员发生过各种各样的的惨剧，但是大多数的事情一而再再而三的重演。

今天的你，可能在开发者各种各样NB的系统，你会相信你的一个空格也能导致系统瘫痪吗？也许你可能很难相信这个事。不过，再下面这个事将告诉你这个血淋淋的事实 —— 一个空格产生的bug可以让你的系统瘫痪。

bumblebee是一个开源项目，这个名字也就是变形金刚里的大黄蜂，这个项目是这样介绍自己的——

bumblebee is Optimus

查看全文: http://www.udpwork.com/item/5305.html

最近，Amazon的新闻比较多，除了Amazon的云平台宕机外，还有一个被热炒的新闻是在Amazon的书店里，有一本书要买$23,698,655.93美元，相当于1亿5千万人民币（如下图所示），这个事情是由UC Berkeley的生物学家Michael Eisen发现的，然后他在他的博客上写了一篇文章来说明这个事情。

这本书是1992年，现在绝版了，生物学家决定上Amazon找一下，结果看到了有两本新书，还有一些二手的，二手书价比较正常，但是那两个新书的价都上了百万。这个生物学家还写了邮件给原作者和原作者开了玩笑。呵呵。

一般人可能就把这个事当成个笑话了，不过，教授就是教授，它还认真的研究了一下为什么会这样。

首先，这个不是A

查看全文: http://www.udpwork.com/item/4947.html

2011年4月12日，Linux 2.6.39-rc3发布了，Linus Torvalds写了一个发布邮件，其中包含了一个长长的为这个版本做过贡献的人员名单，这个名单中有很多看上去应该是中国人的名字，我挺为他们感到骄傲的（不知道你是否还记得以前本站的”Linux是由谁写的“）。

不过，没过一会，发现了一个bug，经过大家的调查（2.6.38版没有发现这个问题），很快，找到了原因，是因为一个内存地址的问题，一个叫Yinghai Lu的人（看其名字应该是中国人，其邮件是@kernel.org）找到了原因—— radeon card使用了一个不正确的内存地址[0xa0000000 - 0xc000000]。Joe

查看全文: http://www.udpwork.com/item/4936.html

以前本站向大家介绍过一些软件开发的原则，比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识，正如我在《再谈“我是怎么招聘程序”》中所说的，一个好的程序员通常由其操作技能、知识水平，经验层力和能力四个方面组成。在这里想和大家说说设计中的一些原则，我认为这些东西属于长期经验总结出来的知识。这些原则，每一个程序员都应该了解。但是请不要教条主义，在使用的时候还是要多多考虑实际情况。其实，下面这些原则，不单单只是软件开发，可以推广到其它生产活动中，甚至我们的生活中。

Don’t Repeat Yourself (DRY)

DRY 是一个最简单的法则，也是最容易被理解的。

查看全文: http://www.udpwork.com/item/4920.html

打印质数的算法应该是学习计算机编程的一个经典的问题，在这里想给大家展示一些方法，相信这些方法会对你的编程有一定的启发作用。请你注意几点，

实际应用和教学应用有很大的差别。

最后的那个使用编译时而不是运行时的方法大家可以重点看看。

教科书的示例

首先，先给一个教科书的示例。下面这个示例应该是教科书（至少是我上大学时的教科学）中算法复杂度最好的例子了。其想法很简单，先写一个判断是否是质数的函数isPrime()，然后从1到n分别调用isPrime()函数来检查。检查是否是质数的算法是核心，其简单的使用从2到n的开根的数作为除数。这样的算法复杂度几乎是O(n*log(n))，看上去不错，但其实很不经济。

#include <

查看全文: http://www.udpwork.com/item/4379.html

还记得以前和大家提到过的《各种流行的编程风格》吗？有一些人问我那些编程风格具体是什么样子的。下面是一个代码重构的实例，让我们看看那个流行的编程风格是实践是什么样的。下面的这个实践不是虚构，如有雷同，请对号入座。

首先，我们有一个表达式如下所示：

s = 7;

很明显，这个表达式的变量名太没意义了，很不利于程序的可读性，所以，我们需要取一个有意义的变量名：

slots = 7;

很好，不过，那个常量7是hard-code或是一个Magic number，而且，这常量没有名字也不利于代码的可读性啊。再改：

SEVEN = 7;
...
slots = SEVEN;

靠！上面，是这是哪门子的改法？（不过，我保证这是真实发生的

查看全文: http://www.udpwork.com/item/2835.html

下面是一个程序员coding的时间分配图，原图在这里。

编程时间分配图

思考会是一个很重要的过程，当然耽搁拖沓也有可能也是因为没有想好，抽烟/喝咖啡应该也是一种思考，吃点东西是为了让脑子转得更快一点，上网搜索一下灵感可以借鉴一下其它人的想法，抱怨写注释只是一个例子，更多的应该是抱怨加班或是公司的老板。

如果需要加上点什么的话，我觉得应该加点“重构”，“编译”，“调试”，当然，他们都可以算在coding里。不过，我觉得更应该还有：“开会”，“争吵/解释”，“打断”，这些比重也是很大的。

所以，下面是我个人认为比较实际的版本：

编程时间图（酷壳版）

你的编程时间分配图是怎么样的？

相关文章
2010年09月25日 -- 代

查看全文: http://www.udpwork.com/item/2793.html

本文译自Dr. Dobb’s Blogger的Walter Bright写的《Overlooked Essentials For Optimizing Code

》

我编写程序至今有35年了，我做了很多关于程序执行速度方面优化的工(一个示例)，我也看过其它人做的优化。我发现有两个最基本的优化技术总是被人所忽略。 注意，这两个技术并不是避免时机不成熟的优化。并不是把冒泡排序变成快速排序（算法优化）。也不是语言或是编译器的优化。也不是把 i*4写成i<<2 的优化。 这两个技术是：

使用 一个profiler。

查看程序执行时的汇编码。

使用这两个技术的人将会成功地写出运行快的代码，不会使用这两个技

查看全文: http://www.udpwork.com/item/2764.html

以前本站发布过《22条经典的编程引言》、《编程引言补充》、《Linus Torvalds 语录》还有《十条不错的编程观点》。今天向大家介绍“最佳编程语录”，条条都是很不错的语录，如同我们的太阳，照亮了我们的方向（所以我们选用了一个红色的图片，希望能够通过五毛们的网络审查）。其中只有一两条在以前本站发布过的文章中出现过。这篇文章的出处在这里，下面是“Neo”和“陈皓”的翻译，我们的翻译水平有限，所以，我们提供了中英文对照，有不当之处，还请各位指正。

A good programmer is someone who looks both ways before crossing a one-way street. —

查看全文: http://www.udpwork.com/item/2268.html

在酷壳，有很多文章都提到了代码注释，如：《十条不错的编程观点》、《优质代码的十诫》、《整洁代码的4个提示》、《惹恼程序员的十件事》等等。今天，某国外的程序员在这里列举五种应该避免的程序注释，我觉得比较有道理，但我觉得有少数几个观点也并不绝对。所以，我把原文的这五种应该避免的程序注释罗列在下面，并放上原作者和我的个人观点作为比较。希望对大家有用。

一、自恋型注释

（注：原文为Proud，我觉得“自恋”更好一点）

public class Program
{
static void Main(string[] args)
{
string message = "Hello World!&q

查看全文: http://www.udpwork.com/item/2221.html

写了小程序(pickupnewords.py)可以找出文本中的英文生词，比如你在观影前可以找出英文字幕中你不认识的单词，逐一查明，这样就不会边看边查字典了，打扰你欣赏电影了 ^_^

程序最新源代码在github。下面简单说明一些关于这个程序的东西。

我这程序肯定无法强大到能读取你大脑的信息得知你认不认识某个单词，它要借助本地存储，其实就是一个用pickle模块把你已经认识的单词集合写入到一个文件里，程序因此有了依据。当然了不可能把’is’、’apple’这样的词也判为生词，因此得有个基础单词库，我用的是Oxford 3000 wordlist，这个是牛津字典的单词释义所用的基础单词

查看全文: http://www.udpwork.com/item/941.html