I don't know when I translated his weblogs from several Taiwanese.), "Zur Talk Software" seems to be favored by more and more programmers. However, telling the truth, I am very displaced with this Zur's argument. Take a look at this paragraph:
"In any case, I don't think Extreme Programming is a concept of advocating zero design. They just said:" Don't make anything unnecessary design. "But people heard is not the case. Most programs The member is looking for an excuse to design, so they are like a moth to swim, and this is a strange, let you have a half-time lazy way. I am too lazy to give this feature on the paper Ok, so I will write the program first, then I find it wrong, I will change it, the result is more time. Or, more often, I will write some programs first, I found it wrong, but I don't have time to change. As a result, my product is poor, and I still have to find some excuses, indicating why it "must be like that." That is just a horse tible, lack of professionalism. "
YUCK, this XP critics really know what XP is doing? His criticized is not XP, just something in his heart wants to criticize. But I don't want to say anything more, Cameron Purdy is more appropriate to evaluate him: This is a programmer who stayed in C years. Perhaps he is only (not Qi, unfortunately) in Java or C #, inherited the language of C , and issued some obsolete mournful.
------------
Poor sod .. Joelonsoftware Used to be a really good read. Lately, It's Been Joelonjoel, And throw in some of this 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 does not reveal potential bugs. They create 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 do not catch too 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 did not think about.A better alternative is to have your functions return error values when things Go WRONG, AND TO DEAL WITESE 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 does not 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 "HO W to Code Windows NT 3.1 Applications In C "Book and Writing Even Make Good Examples for" Writing Solid Code "- IF IT Hadn't Already Been Written 10 Years Ago, That Is. I Welln't Have Had A Problem with What What What 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 '
