News: Six Principles For Programming

  1. Six Principles For Programming (9 messages)

    The Empathy Box blog has "5 Principles For Programming," which details six fairly popular ideas in one handy reference: fail fast, write less code (and don't repeat yourself), computer programs are for people, do the right thing, reduce state, and know your 'stuff.' Failing fast refers to causing large, visible, impossible-to-ignore exceptions when things go wrong, to get rid of the possibility of subtle bugs persisting through various QA cycles. Writing less code (which should be fairly obvious!) includes benefits like making the problem you're trying to solve very clear. Computer programs being for people refers to literate programming, meaning that the consumers of code aren't compilers, but other people:
    We know that c/java/lisp/haskell have not one bit of power that isn't in simple assembly langauge–they only allow us to express the ideas more clearly and prevent certain kinds of stupid mistakes. There is no program that can be written in one that can’t be written in another, and all end up as machine instructions sooner or later (some at compile time, some at run time, but no matter). Given this fact it should be obvious that the only reason to have a programming language is to communicate to a person. Don Knuth wrote about this idea, calling it Literate Programming, and created a system called WEB which was a great idea mired in a terrible implementation. The idea was to embed the program in an essay about the program that explained how it worked.
    Doing the right thing refers to actually coding a solution rather than hacking through something that apparently works.
    I know the best solution but it requires changing things. In my experience every single factor in the software development process will argue for doing the wrong thing: schedules, managers, coworkers, and even, when they get involved, customers. All of these groups want things working as soon as possible, and they don’t care what is done to accomplish that. But no one can see the trade-off being made except for the programmers working on the code. And each of these hacks seems to come back like the ghost of Christmas past in the form of P0 bugs, and I end up doing the right thing then under great pressure and at higher cost then I would have done it before.
    Reducing state refers to simplifying code, especially with respect to concurrency, which can have strange implications with code like x.equals(x), which can return false in some circumstances (depending, of course, on how x.equals(Object) is coded.) Finally, "know your stuff":
    Just as the workable solution is always the last thing you try, the impossibly to diagnose bug is always in the software layer you don’t understand. You have to understand all layers that directly surround your code—for most programmers this begins with the OS. If you do low level programming you better know about computer architecture too. But this idea is bigger that just catching obscure bugs, it has to do with finding the solution to hard problems. Someone who is familiar with the internals of an OS has enough of the big ideas under their belt to attack most large software problems.
    Any additions to these?

    Threaded Messages (9)

  2. In 'The Art of Unix Programming' Eric S. Raymond describes the 'Basics of the Unix Philosophy' http://catb.org/~esr/writings/taoup/html/ . Some of the rules in the book are similar to the above principles. His summary, 'The Unix Philosophy in One Lesson', must seem strange to most Java framework designers (http://catb.org/~esr/writings/taoup/html/ch01s07.html).
  3. Re: Any additions to these?[ Go to top ]

    How about this : "Don't be a Jerk". Seriously, even when we leave code behind, sometimes we not being nice comes through in the code. What I mean specifically about this is that designing and writing software, is such a human based activity, as in any other creative disciplines, that as soon as we introduce the collaborative nature of it and the longevity of the code we leave behind, it becomes more and more important to stress the dynamics of the individuals and the team. In any case, noone likes the disgruntled jaded programmer who thinks they are too good for what they are doing. Its often tolerated much too long, and eventually, they either grow up, or move on and do it again somewhere else, leaving behind a trail of pulled hair and frustration ;-) Jin
  4. Excellent post.
  5. I have to agree with the 'write short functions' advice. It probably is one of the best pieces of advice you can give to new programmers. Good read, btw.
  6. Do the right thing[ Go to top ]

    Re: do the right thing, still one of my favorite analogies: http://www.artima.com/intv/fixitP.html
  7. Write less code always ?[ Go to top ]

    I think someone else said once something like "if you code get too complex add more classes". But if the intent is to said "add only the necessary abstraction layer" I could not agree more. Guido.
  8. deleting code[ Go to top ]

    I can only know that something is going mature when I start deleting code and clases. It 's a great sensation to say "this code/class is no longer needed". It shows that things are going cleaner, smaller and easier.
  9. Chinese translation[ Go to top ]

    Empathy Box在blog中介绍了编程应该注意的5个问题,这篇文章实际表述了编程时应引起注意的很重要的6个思想: 快速失败;写更少的代码(不要让自己重复);程序是写给人看的;做正确的事情;消减状态;了解你的“创造” (fail fast, write less code (and don't repeat yourself), computer programs are for people, do the right thing, reduce state, and know your 'stuff.') 快速失败:当程序出现问题时,产生大的、可见的、不可忽视的异常。以防止不明显的bug一遍遍逃过QA的检查。把隐藏在深处的问题暴露出来。 写更少的代码(似乎是理所当然的):去除冗余,即把程序所要解决的问题展示得更加清晰、明了。 程序是写给人看的:即“学识编程”(Literate Programming),我们程序的读者是其他的人而不是编译器。我们知道c/java/lisp/haskell这些编程语言并不比简单的汇编更加强大,之所以我们使用它们,是因为它们的表述更加清晰,更不容易范些低级的错误。没有任何一个程序能做到只能用一种书写,而不能用另一种,而且,这些语句,最终都要被翻译成机器指令(有些在运行期,有些在编译期,不过都不重要),如此说来,我们使用高级程序设计语言的唯一理由就是——和人进行交流。Don Knuth写下了这个想法,并把它命名为“Literate Programming”,他还设计了一个叫WEB的系统,他的想法非常出色,但他的实现却很糟糕。他的想法是:在程序中加入一篇说明程序是如何运行的的文章。 做正确的事情:实际编程去让正确的程序去做正确的事情,而不是写一个看似正常工作程序。 我知道最佳的解决方案,但需要改变许多东西。在我的经验里,经常有让你做错误事情的机会:计划、经理、合作者,甚至是参与到项目中来的客户,这些群体都想尽快看到你的可以工作的程序,他们并不关系你是如何写这些程序的。但除了事实上写这些程序的程序员外,没有人知道,在编码过程中所作的权衡、割舍。然后隐藏在代码背后的问题就会像圣诞节的幽灵一样以P0 bugs的形式出现(P0 bug:致命缺陷——译者注)。最终,我不得不顶着上面巨大的压力,带给公司更多的花费。让早就该做好的程序去做正确的事情。 消减状态:即简化代码,尤其要注意并发的情况,这时会出现如:x.equals(x)这样的奇怪代码,而且在一些特殊的情况下会返回false,当然,这取决于x.equals(Object)是怎样编码的。 了解你的“创造”:正如可工作的解决方案总是你尝试的最后一个解决方案一样,无法诊断的bug总是存在于你还不了解的软件层中。你必须去了解直接包裹在你代码周围的那些层——对于大多数程序员来说,这可能意味着要从操作系统开始。如果你从事底层编程,你很可能还要了解一些计算机体系结构。但这个观点比直接找到隐藏的bug要大,主要用来清除那些不易解决的问题,一个了解操作系统内核的人,一定有能力去解决他们遇到的绝大多数问题。
  10. We are always told we should make the function simple and short? Did any one ever thought how short a method can be?I think this depends on the problem that you solve. Any problem can calculated to amount of status point in a context. If every status of your method is directly cresponding to your every status of your problem without duplcates, that can be said the should-be-enough-short method. This is also applied to the Class. Just my 0.1 cents.