不知道什么时候（大概是从几个台湾人翻译了他的weblogs开始吧），“祖尔谈软件”似乎受到了越来越多程序员的青睐。不过，说实话，我很反感这位祖尔的论调。看看这段话吧：
“不管怎么说，我不认为Extreme Programming是在鼓吹零设计的理念。他们只是说：“不要作任何无必要的设计”，这没有什么错嘛。但人们听到的并不是这样。大多数程序员是在找不用设计的借口，所以他们像飞蛾扑火般投向“不用设计” 这个馊主意。这是一种奇怪的，让你事倍功半的懒惰方式。我懒得先在纸上把这个功能给设计好了，所以我就先写程序，然后发现不对，我就去改，结果反倒花更多的时间。或者，更经常发生的是，我先写些程序，发现它不对，但是没时间改了，结果我的产品质量低劣，而且我还是要找出些借口，说明它为什么“一定要那样“。那只不过是马虎潦草，缺乏职业精神。”
yuck，这位XP的批评者真的知道XP是在干什么吗？他批评的不是XP，只是他心里想批评的东西而已。不过我不想再多说什么，Cameron Purdy对他的评价更加恰当：这是一个停留在C++年代的程序员。也许，他只是（不巧地、不幸地）在Java或者C#里遗传了C++的语意，并发出了一些过时的悲叹。
————————
Poor sod ..
JoelOnSoftware used to be a really good read. Lately, it's been JoelOnJoel, and throw in some of that 1990s programming stuff just to sound technical. Take today's post as an example:
... I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:
They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn't reveal potential bugs.
They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.
A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be.
I'm speechless. (Well, that's not very likely. What I mean is that this guy is waxing clueless.) Let me start by saying that I like his rationale: Unknowns can lead to bugs, and by making everything known, bugs can be eliminated. I mean, come on, who doesn't want to exterminate entire families of bugs? I've coded reams of C++ code that did exactly Joel suggests, and he's right, being extra-anal with immediate error handling and well designed unambiguous return values does improve the quality of code. In C++.
Of course, maybe Joel is still coding in C++. Obviously, he's not coding in Java, which he likes to talk about in the article. The thing is, in Java, which is what most new projects are being built in (or it's cousin C# for Windows shops), using return values as he describes is an anathema. Reading his blog, I feel like how I did back when C programmers were trying to tell me how to build COM applications in C++ .. in fact, his code examples look like they are straight out of a "How to Code Windows NT 3.1 applications in C" book and would even make good examples for "Writing Solid Code" -- if it hadn't already been written 10 years ago, that is.
I wouldn't have had a problem with what he wrote, if he could have stopped with "C/C++", but he somehow assumes that since Java (also C#) generally shares the C/C++ syntax, that it must suffer from the same weaknesses. Java was designed from the ground up around good exception handling; it's not a glue-on long-jump afterthought. With these modern languages, exceptions are generally exceptional, which is to say that just about any line of code can theoretically throw an exception (I use the term "exception" in the loose sense that includes an "error" in Java), and the behavior of exceptions is very well defined and fairly logical.
Even catching all possible exceptions where they occur in Java is basically impossible .. by design. It reflects reality, instead of (as in C++) the assembly code that the source code generates. Furthermore, in Java, if you will purposefully throw something, you get to declare that exception as a checked exception, largely mitigating one of Joel's other concerns. (In C#, there are no checked exceptions, but you can still write comments saying what your code throws, which is a reasonable trade-off for being able to build Windows Forms in COBOL.)
So do yourself a favor: If you're coding in Java or C#, ignore his advice. The 90s are over and have been for a couple years. I don't like to have to explain OO to C coders (they still say "What's the big deal? I can do all that with structs and function pointers!") and I don't want to explain modern exception handling to people polluting their code with reams of brittle "if" statements under some delusion that they are actually handling exceptional conditions.
