Browsed by
标签:程序员

千万不要把 bool 设计成函数参数

千万不要把 bool 设计成函数参数

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

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

widget->repaint(false);

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

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

InvalidateRect(hwnd, lpRect,  false);

我们先不说InvalidateRect这个函数名取得有多糟糕,我们先说一下那个false参数?invalidate意为“让XXX无效”,false是什么意思?双重否定?是肯定的意思?如果你看到这样的代码,你会相当的费解的。于是,你要去看一下文档,或是InvalidateRect的函数定义,你会看到那个参数是 BOOL bErase,意思是,是否要重画背景。

这样的事情有很多,再看下面的代码,想把str中的”%USER%”替换成真实的用户名:

str.replace("%USER%", user, false);   // Qt 3

TNND,那个false是什么意思?不替换吗?还是别的什么意思,看了文档才知道,false代码大小写不敏感的替换。

其实,如果你使用枚举变量/常量,而不是bool变量,你会让你的代码更易读,如:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (27 人打了分,平均分: 4.30 )
Loading...
C语言中史上最愚蠢的Bug

C语言中史上最愚蠢的Bug

本文来自“The most stupid C bug ever”,很有意思,分享给大家。我相信这样的bug,就算你是高手你也会犯的。你来看看作者犯的这个Bug吧。。

首先,作者想用一段程序来创建一个文件,如果有文件名的话,就创建真正的文件,如果没有的话,就调用?tmpfile()?创建临时文件。他这段程序就是HTTP下载的C程序。code==200就是HTTP的返回码。

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */
    g = fname ? fopen(fname, "w+") : tmpfile();
}

但是这个程序,只能在Unix/Linux下工作,因为 Microsoft 的?tmpfile()的实现?居然选择了 C:\ 作为临时文件的存放目录,这对于那些没有管理员权限的人来说就出大问题了,在Windows 7下,就算你有管理员权限也会有问题。所以,上面的程序在Windows平台下需要用不同的方式来处理,不能直接使用Windows的tmpfile()函数。

于是作者就先把这个问题记下来,在注释中写下了FIXME:

else if (code == 200) {     // Downloading whole file
    /* Write new file (plus allow reading once we finish) */

    // FIXME Win32 native version fails here because
    //   Microsoft's version of tmpfile() creates the file in C:\
    g = fname ? fopen(fname, "w+") : tmpfile();
}

然后,作者觉得需要写一个跨平台的编译:

FILE * tmpfile ( void ) {
#ifndef _WIN32
    return tmpfile();
#else
    //code for Windows;
#endif
}

然后,作者觉得这样实现很不好,会发现名字冲突,因为这样一来这个函数太难看了。于是他重构了一下他的代码——写一个自己实现的tmpfile() – w32_tmpfile,然后,在Windows 下用宏定义来重命名这个函数为tmpfile()。(陈皓注:这种用法是比较标准的跨平台代码的写法)

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (37 人打了分,平均分: 4.73 )
Loading...
弱爆程序员的特征值

弱爆程序员的特征值

感谢网友投递此文,很欢乐也有意思,与大家共勉

首先说明:

1、以下特征是真实遇到过的,同事犯过的,乃至我自己也犯过的;
2、为了剧情需要,某些例子进行了一些夸张修饰等演绎创作,如无雷同,请勿生气;
3、如果你出现过以下症状之一,并不代表你就是弱爆了,但是如果你一直出现,乃至一说到这个大家就能联想到你,那么你就得小心了;
4、如果你是集这几个的大乘者,恭喜你,你已经找到了离开这个行业的充足理由了。

好了,搞定!

“那个Bug解决了吗?”

“好了,搞定!”

“这么快?”

正当你非常欣喜的时候,就传来了噩耗:刚才还能编译成功的,就失败了。(好吧,我们的集成编译尚未成功配置上,理论上这种事情应该会被退回。)又或者能编译成功,但是呢,原来明明能起作用的一个下拉框,突然发神经的不起作用了。最隐蔽的莫过于,一切正常,但是当你看到代码的时候,你就晕厥过去了。比如我们曾经发现了一个Bug,简单说就是每次用户点击某个东西,就会执行下面的这段C#代码:

controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

这个Bug很明显会导致速度越来越慢,因为同一个更新操作会被更新N次,并且这个N会越来越大。其实这个Bug已经够弱了,但是后来居然被修改为:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (19 人打了分,平均分: 4.42 )
Loading...
重构代码的7个阶段

重构代码的7个阶段

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

第一阶段 – 绝望

在你开始去查看你想要重构的模块的,你会觉得好像很简单,这里需要改一个类,那里需要改两到三个函数,重写几个函数,看上去没什么大不了的,一两天就搞定了。于是你着手开始重构,然后当你调整重构了一些代码,比如改了一些命名,修理了一些逻辑,渐渐地,你会发现这个怪物原来体型这么大,你会看到与代码不符甚至含糊不清的注释,完全摸不着头脑的数据结构,还有一些看似不需要方法被调了几次,你还会发现无法搞清一个函数调用链上的逻辑。你感到这个事可能一周都搞不定,你开始绝望了。

第二阶段 – 找最简单的做

你承认你要重构的这个模块就是一个可怕的怪物,不是一两下就可以搞定的,于是你开始着干一些简单的事,比如重新命名一下几个函数,移除一些代码的阻碍,产生几个常量来消除magic number,等等,你知道这样做至少不会让代码变得更糟糕。

第三阶段 – 再次绝望

但是接下来的事会让你再次撞墙。你会发现那些代码的瑕疵是些不痛不痒的事,改正这些事完全于事无补,你应该要做的事就是重写所有的东西。但是你却没有时间这么干,而这些代码剪不乱理还乱,耦合得太多,让你再一次绝望。所以,你只能部分重写那些不会花太多时间的部分,这样至少可以让这些老的代码能被更多的重用。虽然不完美,但是至少可以试试。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (24 人打了分,平均分: 4.79 )
Loading...
你确信你了解时间吗?

你确信你了解时间吗?

你还记得“软件真的好难做”中的那个有意思的例子吗?那个例子告诉我们软件开发中假设可能会是致命的事。今天,我又在StackOverflow上看到一个关于时间的问题——为什么1927年12月31日的午夜时间这么奇怪?提问题的这个人给了下面的一段java代码(我做一些修改,保证让你可以copy过去就可以编译运行)

我在其中高亮了几行,这个程序就是想比较一下“1927-12-31 23:54:07”  和  “1927-12-31 23:54:08” 差几秒,很明显,是差一秒。但是程序的输出却不是这样的。

import java.text.SimpleDateFormat;
import java.text.ParseException;
import java.util.Date;
import java.util.TimeZone;
class time{
    public static void main(String[] args) throws ParseException {
        SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        sf.setTimeZone(TimeZone.getTimeZone("Asia/shanghai"));
        String str3 = "1927-12-31 23:54:07";
        String str4 = "1927-12-31 23:54:08";
        Date sDt3 = sf.parse(str3);
        Date sDt4 = sf.parse(str4);
        long ld3 = sDt3.getTime() /1000;
        long ld4 = sDt4.getTime() /1000;
        System.out.println(ld3);
        System.out.println(ld4);
        System.out.println(ld4-ld3);
    }
}

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 4.88 )
Loading...
程序员技术练级攻略

程序员技术练级攻略

月光博客6月12日发表了《写给新手程序员的一封信》,翻译自《An open letter to those who want to start programming》,我的朋友(他在本站的id是Mailper)告诉我,他希望在酷壳上看到一篇更具操作性的文章。因为他也是喜欢编程和技术的家伙,于是,我让他把他的一些学习Python和Web编程的一些点滴总结一下。于是他给我发来了一些他的心得和经历,我在把他的心得做了不多的增改,并根据我的经历增加了“进阶”一节。这是一篇由新手和我这个老家伙根据我们的经历完成的文章

我的这个朋友把这篇文章取名叫Build Your Programming Technical Skills,我实在不知道用中文怎么翻译,但我在写的过程中,我觉得这很像一个打网游做任务升级的一个过程,所以取名叫“技术练级攻略”,题目有点大,呵呵,这个标题纯粹是为了好玩这里仅仅是在分享Mailper和我个人的学习经历。(注:省去了我作为一个初学者曾经学习过的一些技术(今天明显过时了),如:Delphi/Power builder,也省去了我学过的一些我觉得没意思的技术Lotus Notes/ActiveX/COM/ADO/ATL/.NET ……)

前言

你是否觉得自己从学校毕业的时候只做过小玩具一样的程序?走入职场后哪怕没有什么经验也可以把以下这些课外练习走一遍(朋友的抱怨:学校课程总是从理论出发,作业项目都看不出有什么实际作用,不如从工作中的需求出发)

建议:

  • 不要乱买书,不要乱追新技术新名词,基础的东西经过很长时间积累而且还会在未来至少10年通用。
  • 回顾一下历史,看看历史上时间线上技术的发展,你才能明白明天会是什么样。
  • 一定要动手,例子不管多么简单,建议至少自己手敲一遍看看是否理解了里头的细枝末节。
  • 一定要学会思考,思考为什么要这样,而不是那样。还要举一反三地思考。

:你也许会很奇怪为什么下面的东西很偏Unix/Linux,这是因为我觉得Windows下的编程可能会在未来很没有前途,原因如下:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (250 人打了分,平均分: 4.84 )
Loading...
给程序员新手的一些建议

给程序员新手的一些建议

前段时间因为实习生计划花了很多时间做了实习生招聘的工作,产生的一些想法,写在这里。

这次招聘过程中,我发现我们在校的学生有下面的这些特点:

1)NB的项目。当说到自己做过的项目时, 我发现他们做的事都是很NB。要么是研究Linux的底层内核,要么是图像识别处理,要么是推荐算法,要么做高性能计算,要么做数据挖掘,要么是移动方面的协议,还有一些很高深的课题我听不太懂的项目。这让我想起当年我在学校里的实习,对比起我用Java Applet 和 HTML做操作系统的教学课件,或是在公司里用Delphi/PowerBuilder做的那些MIS系统。让我觉得有些汗颜。

2)OK的解决问题能力。当问到算法题时,我发现他们的问题解决能力还OK。我一般问1到2个中低难度的算法题和1个基本的面向对象设计的题,都不难。我相信只要在学校里好好学习的人都应该答得出来。无非就是一些基本的算法和基本数据结构操作的问题,和比较基础的面向对象设计的题,说白了就是作业题。可惜的是,只有5%不到的同学能够在不给提示的情况下答出来,70%的人可以在给一定的提示下答出来,15%左右的同学需要提示到几乎给出答案才能答出来,还有10%的同学怎么给提示都答不出来。

3)WTF的编码能力。老实说,对于解算法题,我还是比较可以接受的,因为80%左右的同学在给予提示后都能描述出解题的算法,于是,我让他们把这个算法用他们最熟悉的语言写出来。但结果让我出乎意料,一段在解法很清楚的情况下只需要不到30行代码的小算法题,只有一个人能在10分钟几写完,其它的人基本所有的需要30分钟左右(甚至40分钟),有2、3个人居然写不出来。有一个比较极端的case是——有个同学花了十分钟都写不出从一个整型数组中找到最小的正数的代码。这个事让我觉得很惊讶,难道大家在做项目的时候不编程吗?

对于这种情况,我想给大家以下后一些建议:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (51 人打了分,平均分: 4.76 )
Loading...
软件公司的两种管理方式

软件公司的两种管理方式

这篇文章是我的一个外国的同事Gareth推荐给我的,我和他一起工作过一段时间。他之所以觉得非常不错,是因为这篇文章让他身有体会,他觉得我也一定会有体会,并让我考虑一下翻译到我的blog上来。我看完后觉得很有代表性,而且觉得说得太对了,所以翻译过来,希望大家都读一读,最好转给你的公司老板

这篇文章来源于 StakeExchange上的一个问题——“为什么BA和PM的薪水要比程序员要高?”,顶在一楼的回复分析了这个原因,并指出了两种管理文化。

———————————————————正文开始————————————————————

一个简单的回答应该是——“因为在我们的社会里,我们总是会认为薪水和会和职位的层次绑在一起”。但是,这个答案同时也折射出一个事实——我们的薪资是基于我们的所理解的价值,但这并没有解释

  1. 为什么PM(Project Manager)和BA(Business Analysts)在很多软件公司里在组织的上层?
  2. 为什么软件项目团队总是在最底层?

这两个问题真是非常地值得我们去问,去思考。

总体来说,这个世界上存在两种不同的软件公司的组织结构。我把他们叫做 Widget Factory(小商品工厂) 和 Film Crews(电影工作组).

Widget Factories 想要去解决 怎么去激发被X理论所影响的人 。X理论由 McGregor提出,这个理论是说,一般人的本性是懒惰的,工作越少越好,可能的话会逃避工作,大部分人对集体(公司,机构,单位或组织等)的目标不关心,因此管理者需要以强迫,威胁处罚,指导,金钱利益等诱因激发人们的工作源动力。于是,经理总是要去做他下属的工作。于是,基于这种前提下所思考出来的管理方式,很自然的就是——整个团队能够容易地被经理一个人所取代,这种团队中的每一个人都很容易被别人取代,在这种团队里,经理的工作能力不断地被加强。因些,这种公司一般使用树形层级的组织结构,而不是水平式的工作角色。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (37 人打了分,平均分: 4.81 )
Loading...
一个空格引发的惨剧

一个空格引发的惨剧

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

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

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

bumblebee is Optimus support for Linux, with real offloading, and not switchable graphics.. More important.. it works on Optimus Laptops without a graphical multiplexer..

Optimus 是NVIDIA的“优驰”技术,其可以将您的笔记本电脑PC提升到绝佳状态,提供出色的图形性能,并在需要时延长电池续航时间。这个项目是把这个技术移到Linux上来。

这个项目本来不出名,不过,程序在其安装脚本install.sh里的一个bug让这个项目一下子成了全世界最瞩目的项目,这个bug的fix如下:

@@ -348,7 +348,7 @@ case "$DISTRO" in
-  rm -rf /usr /lib/nvidia-current/xorg/xorg
+  rm -rf /usr/lib/nvidia-current/xorg/xorg

看明白了吗?空格。这个空格会导致什么样的问题呢?呵呵。你有没有感到菊花一紧?这个bug绝对的霸气外露!真是验证了“如何写出无法维护代码”的那句话——“测试你的程序是一种懦夫的行为”。

不过,最精彩还不是这个bug,而是全世界程序员的对这个bug 的 code review comments,真的相当的欢乐。请强势围望!

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (14 人打了分,平均分: 4.86 )
Loading...
“另类” 设计模式

“另类” 设计模式

下面这篇文章来自这里:http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns,这篇文章有点意思了,山寨了我们著名的Design Pattern。这篇文章并不是很容易翻译,也许我翻译的不好,大家多指正。另外,这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词,一走眼你还以为是正二八经的设计模式。呵呵。所以,我在下文中,我会保留原有的英文单词,并把真正的23个经典设计模式的英文名放在旁边(灰色)。这篇文章和之前的如何写出无法维护的代码有异曲同工,个人感觉都是比较欢乐的。

 

辞职模式
Resign Patterns
Design Patterns

不合式的非面向项目软件开发病症
Ailments of Unsuitable Project-Disoriented Software
Elements of Reusable Object-Oriented Software
作者Michael Duell

概要

任何一个熟悉那本由四个人写的经典的设计模式书的朋友,应该知道那本书里的模式都是非常优雅和划时代的。然而,不幸的是,从那些老代码中无法提练出这些模式,因为,在出现这些模式前,大家都不会使用模式。因此,这项工作是从大量的代码中提练出一个模式的目录。这些模式都有充足和永恒的示例。希望你能享受阅读这些模式,但千万不要模仿并使用他们!

1. Cremational Patterns 火葬模式 | Creational patterns 创建模式

下面是五个 cremational patterns.
1.1 Abject Poverty  一贫如洗 | Abstract Factory 抽象工厂

Abject Poverty 模式能让你的软件相当难测试和维护, 并且需要巨大的财政支出,预算已经完全赤字。

1.2 Blinder 眼罩模式 | Builder 建造模式

Blinder 模式是一个应急有效的解决方案,其不需要考虑需求在未来的变化。目前,我们还不太清楚我们为什么叫Blinder模式,一种说法是他们会在写代码的时候被设计人员戴上眼罩,另一种说法是他们希望在维护代码的时候挖出双眼。

1.3 Fallacy Method 错误方法 | Factory method 工厂方法

Fallacy方法主要是在于处理一些不明显的案例。代码逻辑看上去是正确的,当只要某想要去测试一下,或是某个不明显的案例发生了,那些代码中的错误也就出现了。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (14 人打了分,平均分: 4.86 )
Loading...