Browsed by
分类:程序设计

十条不错的编程观点

十条不错的编程观点

Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》,翻译成中文就是“你认为最有争议的编程观点是什么?”,不过,在400多个主回贴,以及千把个子回贴中,好像并不是很有争议,而是令人相当的茅塞顿开,下面罗列一些,并通过我自己的经历和理解发挥了一些,希望对你有帮助。

1) The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式,框架,那些著名的方法、模式、框架只代码赞同他们的人多,并不代表他们适合你,你应该更多的去使用你的大脑,独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想,那才是“best practice”。事实上来说,那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。

2)Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你对编程没有感到一种快乐,没有在你空闲的时候去以一种的娱乐方式去生活,无论是编程,还是运动,还是去旅游,那么你只不过是在应付你的工作,无时无刻不扎在程序堆中,这样下来,就算是你是一个非常聪明,非常有才华的人,你也不会成为一个优秀的编程员,要么只会平平凡凡,要么只会整天扎在技术中成为书呆子。当然,这个观点是有争议,热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。

3)Most comments in code are in fact a pernicious form of code duplication.

注释应该是注释Why,而不是How和What,参看《惹恼程序员的十件事》,代码告诉你How,而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释,那些注释其实和code是重复的,毫无意义。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (47 人打了分,平均分: 4.70 )
Loading...
各种流行的编程风格

各种流行的编程风格

在过去的N年中,我遇到了很多使用囧然不同风格的开发者,下面是我所知道的一些,你还知道其它的吗?

散弹枪编程

这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯,这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”,当然依然出错,于是我们的程序员会这样:“好吧,那我就注释掉整个方法吧”,或是其它更为随意的处理方式,直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。

如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地,那么,那个正规的程序可以马上变得发疯起来,并且,可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程,这是因为他们破坏性的才能会造成的伤害会比只有一个还差。

撞大运编程

这是一种比散弹枪编程要温和一些的编程方式,我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么,也不知道所写的程序的本质和实际,但是可以让程序工作起来。他们以一种撞大运的方式在写程序,某些时候,他们根本就不知道某个错误的原因,就开始稀里糊涂地修改代码。一旦出现问题,他们会用两条路:1)停下来,理解一下程序,找到出错的原因。2)使用散弹枪编程方式开始解决问题。

测试驱动开发(Test Driven Development)是一种可以用来拯救上百万的撞大运编程的程序员。于是,他们有了一个更为NB的借口:只要我的程序通过测试了,你还有什么话好说?别骂我,测试驱动开发是一个不错的事物,其主要是用来控制撞大运开发所带来的问题。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (45 人打了分,平均分: 4.89 )
Loading...
程序命名的一些提示

程序命名的一些提示

选择一个正确的名字是编程中最重要的事。以前酷壳向大家推荐过两篇文章《编程命名中的7+1个提示》 和《编程中的命名设计那点事》,今天再向大家推荐一篇。一个正确的命名可以让你更容易地理解代码的程序,好的命名可以消除二义性,消除误解,并且说明真实的意图,甚至可以让你有清新的气息以让你更能吸引异性。;-)

方法,类和变量

正确的名字可以让你的程序顾名思义,下面是一些提示:
  • 不要使用”ProcessData()“这样的命名
    你如果在你的程序生涯中使用这样的函数名,那么这意味着你将是一个不合格的程序员而会被淘汰或解雇。请明确实际的功能。比如:ValidateUserLogin(验证用户登录) 或 EliminateDuplicateRequests(去除重复请求) 或 ComputeAverageAge(计算平均年龄),等等。
  • 让命名来帮你设计程序
    让我们假装有这么一条规则是——“任何的函数是有输入/输出的”,那么,你需要思考的是所有的把input变成ouptut的步骤,然后,你可以选择一个简短的句了来说明你的这段程序,然后,把这个短句再精练一下,最终成为你的函数名,而那个短句则成了你程序的结构。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (8 人打了分,平均分: 4.88 )
Loading...
Richard Feynman, 挑战者号, 软件工程

Richard Feynman, 挑战者号, 软件工程

源文:链接  (本文主要根据挑战者号的问题,以及Richard Feynman那对NASA严厉的批评报告,批评了不适当的“自顶向下”的设计方法,并总结了一下软件工程和其它工程的相通的一些观点。翻译水平有限,欢迎指正)

Challenger Crew

佛罗里达州,美国东部时间1986年1月28日上午11时39分,挑战者号航天飞机 执行为期6天的STS-51-L 任务,在发射后,其右侧固体火箭助推器(SRB – Solid Rocket Booster)的O型环密封圈(用于连接两节助推器)失效,泄漏出来的热汽达到了5000华氏度,直接蒸发了O型密封圈,并灼烧了毗邻的外部燃料舱,在几秒钟内,外部燃料舱出现结构连接失效,空气的动力迅速分解了航天飞机。在而航天飞机上升72秒以后,助推器脱落,导致航天发飞向侧面滑出。几乎在引航员 Michael J. Smith 发出”Uh oh” 的同时,整个航天飞机完全解体,片刻,航天飞机内部发生爆炸,所有7名宇航员罹难。 那时的我还只是一个小孩,我从电视下方滚动的新闻条目知道了这一惨剧。

在那个时候,火箭助推器工程师曾经警告过这个O型环可能存在问题,但可惜的是,NASA的管理层忽略了这个问题。Challenger Explosion美国总统里根委派罗杰斯委员会对事故进行了调查,调查成员包括著名的物理学家Richard Feynman。其不羁的态度和直来直去的方法和罗杰斯委员会的风格形成了鲜明的反差。主席罗杰斯,一个政客,评论Feynman是一个“真正的痛苦”。最后,在委员会提交的报告中,Feynman反判的观点几乎被清除了出去。并且,Feynman曾被主席威胁过要把他的名字从报告中完全除掉,但最终,他们还是同意在报告中加一个附录,但只是个人观点—— Appendix F – Personal Observations on Reliability of Shuttle

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 4.53 )
Loading...
使用Flex Bison 和LLVM编写自己的编译器

使用Flex Bison 和LLVM编写自己的编译器

使用Flex Bison 和 LLVM编写你自己的编译器
原文出处:http://gnuu.org/2009/09/18/writing-your-own-toy-compiler

1、介绍

我总是对编译器和语言非常感兴趣,但是兴趣并不会让你走的更远。大量的编译器的设计概念可以搞的任何一个程序员迷失在这些概念之中。不用说,我也曾今尝试过,但是并没有取得太大的成功,我以前的尝试都停留在语义分析阶段。本文的灵感主要来源于我最近一次的尝试,并且在这一次中我取得一点成就。

幸运的是,最近的几年,我参加了一些项目,这些项目给了我在建立编译器上很多有用的经验和观点。另外一件事是,我非常幸运得到LLVM的帮助。对于这个工具,我不知道改怎么去形容它,但是他给我的这个编译器的确带来非常大的帮助。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (22 人打了分,平均分: 4.68 )
Loading...
面试题:赛马问题

面试题:赛马问题

据说,这是Google的面试题。面试题目如下:

Question一共有25匹马,有一个赛场,赛场有5个赛道,就是说最多同时可以有5匹马一起比赛。假设每匹马都跑的很稳定,不用任何其他工具,只通过马与马之间的比赛,试问,最少得比多少场才能知道跑得最快的5匹马?(不能使用撞大运的算法

很明显这是一个算法题,网上有很多贴子在讨论这个问题,不过都没有给出一个明确的答案。我想了想,想到下面的一个算法:

1)分成5组A,B,C,D,E,比五场。然后根据每场结果分别给这五组内的五匹马排序(从快到慢)。
2)每组的头名再赛一场,取走第一名,然后该组第二名顶上。
3)重复第二步,直到选出前5名。

这个算法是比较笨的算法,总计需要赛10次,这个算法应该是万无一失的。现在的问题的就,如何优化这个算法,想了想,的确是有优化的空间的。也就是说,是可以少于10次的。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (18 人打了分,平均分: 4.33 )
Loading...
编程命名中的7+1个提示

编程命名中的7+1个提示

前几天Neo写过《编程中的命名设计那点事》,这里也有另外一篇和程序命名的文章,可以从另一个角度看看。

1.- 变量应该是尽可能的望文知意。千万不要使用教材中的命名方式。

  • 好的变量 daysDateRange, flightNumber, carColor.
  • 坏的变量: days, dRange, temp, data, aux…

在我们的日常工作中,有很大数量的开发人员喜欢使用短的变量名,而不是有含义的变量名。这主要是因为我们大学教科书的那些示例所造成的,人都是先入为主,所以,教科书中的那些很抽象,带着演示的变量命名影响了我们一代又一代的程序员,并影响了他们很多年。虽然那些短的,教材式的变量名,可能会让你少打一些字,但其实,这是非常非常不好的。因为软件的维护成本远远大于了软件的开发成本,如果你不取一个好的一点的变量名,那么当进行代码评审时,当进行bug fixing时,当进行代码重构时,当进行代码维护时,你的某个变量名可能会让你一头雾水,不知道所措,还可以会让你走入陷阱,造成更大的时间成本。所以,一个可阅读的代码必然和那些不错的变量名分不开,而这也能让你的软件间接上有更好的质量。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 4.56 )
Loading...
优质代码的十诫

优质代码的十诫

1.- DRY: Don’t repeat yourself.

10commandementsDRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

DRY 这一法则可能是编程届中最通用的法则了,目前为止,应该没有哪个程序员对这一法则存有异议。但是,我们却能发现,一些程序在编写单元测试(unit testing)时忘记了这一法则:让我们相像一下,当你改变一个类的若干接口,如果你没有使用DRY,那么,那些通过调用一系例类的接口的unit test的程序,都需要被手动的更改。比如:如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法,而是每个test case自己去构造类的实例,那么,当类的构造函数被改变时,你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 4.88 )
Loading...
编程中的命名设计那点事

编程中的命名设计那点事

在我开始设计系统的时候,我会花去很多时间去设计命名,因为好的命名和好的设计是分不开的。

In the beginning was the Word, and the Word was with God, and the Word was God
太初有道。道与神同在,道就是神。 (约翰福音第一章,第一节)

在设计过程中给类,方法和函数好的命名会带来好的设计,虽然这不是一定成立,但是如果坏的命名那一定不会给你带来好的设计。在设计过程,如果你发现你很难命名某一个模块,某个方法时,可能你真正遇到的问题不是难命名的问题,而是这个设计是否真的合理,你或许应该花更多的时间来重新设计一下你的模块。

好的命名不仅会带来好的设计,好的命名还提高了程序的可读性,降低代码维护的成本。另一方面,如果糟糕的命名会给代码带来一堵无形的墙,让你必须深入代码去研究代码具有的行为,增加你理解代码的时间。

为此我总结了几条关于命名的指导原则,希望这几条原则能为你的命名设计带来帮助,我使用的是C++的语法,当然这些原则也很容易扩展到其他语言中去。

类型命名(类,接口,和结构)


名字应该尽量采用名词
Bad:           Happy
Good:          Happiness

阅读全文 Read More

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