Don't be shy, throw an exception. Exceptions are a perfectly valid way to signal failure, and are much clearer than any return-code system. "Exceptional" has nothing to do with how often this can happen, and everything to do with what the class considers normal execution conditions. Throwing an exception when a division by zero occurs is just fine, regardless of how often the case can happen. If the problem is likely, guard your code so that the method doesn't get called with incorrect arguments.

I'd say that my most controversial opinion on programming is that I honestly believe you shouldn't worry so much about throw-away code and rewriting code. Too many times people feel that if you write something down, then changing it means you did something wrong. But the way my brain works is to get something very simple working, and update the code slowly, while ensuring that the code and the test continue to function together. It may end up actually creating classes, methods, additional parameters, etc., I fully well know will go away in a few hours. But I do it because i want to take only small steps toward my goal. In the end, I don't think I spend any more time using this technique than the programmers that stare at the screen trying to figure out the best design up front before writing a line of code.

我得到的好处是，我不必不断地处理那些因为我碰巧以某种方式破坏了它而不再工作的软件，并试图找出停止工作的原因和原因。

不是很有争议，但是… AJAX早在这个术语被创造出来之前就已经存在了，每个人都需要“放手”。人们用它做各种各样的事情。但是没有人真正关心它。

然后突然嘣!有人创造了这个术语，每个人都加入了AJAX的潮流。突然之间，人们成了AJAX的专家，好像动态加载数据的“专家”以前并不存在似的。我认为这是导致互联网被残酷摧毁的最大因素之一。还有“Web 2.0”。

硬编码很好!

真的，在许多情况下更有效，更容易维护!

我看到常数放入参数文件的次数真的非常频繁 你改变了水的冰点还是光速?

对于C程序，只需将这些类型的值硬编码到头文件中，对于java程序，只需将这些值硬编码到静态类中等等。

当这些参数对你的程序行为有巨大的影响时，你真的想对每一个变化做一个回归测试，这似乎是硬编码值更自然。当东西存储在参数/属性文件中时，人们很容易认为“这不是一个程序变更，所以我不需要测试它”。

另一个好处是，它可以防止人们在参数/属性文件中混淆重要值，因为根本没有任何重要值!

您不应该停留在您发现的编写“有效”代码的第一种方法上。

I really don't think this should be controversial, but it is. People see an example from elsewhere in the code, from online, or from some old "Teach yourself Advanced Power SQLJava#BeansServer in 3.14159 minutes" book dated 1999, and they think they know something and they copy it into their code. They don't walk through the example to find out what each line does. They don't think about the design of their program and see if there might be a more organized or more natural way to do the same thing. They don't make any attempt at keeping their skill sets up to date to learn that they are using ideas and methods deprecated in the last year of the previous millenium. They don't seem to have the experience to learn that what they're copying has created specific horrific maintenance burdens for programmers for years and that they can be avoided with a little more thought.

事实上，他们似乎甚至没有意识到做一件事可能有不止一种方法。

I come from the Perl world, where one of the slogans is "There's More Than One Way To Do It." (TMTOWTDI) People who've taken a cursory look at Perl have written it off as "write-only" or "unreadable," largely because they've looked at crappy code written by people with the mindset I described above. Those people have given zero thought to design, maintainability, organization, reduction of duplication in code, coupling, cohesion, encapsulation, etc. They write crap. Those people exist programming in every language, and easy to learn languages with many ways to do things give them plenty of rope and guns to shoot and hang themselves with. Simultaneously.

But if you hang around the Perl world for longer than a cursory look, and watch what the long-timers in the community are doing, you see a remarkable thing: the good Perl programmers spend some time seeking to find the best way to do something. When they're naming a new module, they ask around for suggestions and bounce their ideas off of people. They hand their code out to get looked at, critiqued, and modified. If they have to do something nasty, they encapsulate it in the smallest way possible in a module for use in a more organized way. Several implementations of the same idea might hang around for awhile, but they compete for mindshare and marketshare, and they compete by trying to do the best job, and a big part of that is by making themselves easily maintainable. Really good Perl programmers seem to think hard about what they are doing and looking for the best way to do things, rather than just grabbing the first idea that flits through their brain.

如今，我主要在Java世界中编程。我见过一些非常好的Java代码，但我也见过很多垃圾代码，而且我还看到了更多我在开头描述的心态:人们选择了第一个看起来可以工作的丑陋代码块，而不理解它，也不考虑是否有更好的方法。

You will see both mindsets in every language. I'm not trying to impugn Java specifically. (Actually I really like it in some ways ... maybe that should be my real controversial opinion!) But I'm coming to believe that every programmer needs to spend a good couple of years with a TMTOWTDI-style language, because even though conventional wisdom has it that this leads to chaos and crappy code, it actually seems to produce people who understand that you need to think about the repercussions of what you are doing instead of trusting your language to have been designed to make you do the right thing with no effort.

我确实认为你可能会在另一个方向上走得太远:例如，完美主义完全忽略了你的真正需求和目标(通常是你的业务的真正需求和目标，通常是盈利能力)。但我不认为任何人都能成为一个真正伟大的程序员，除非学会投入一些高于平均水平的努力来思考寻找最好的(或至少是最好的一种)方法来编码他们正在做的事情。

开发人员应该能够在不获得任何人许可的情况下修改产品代码，只要他们记录了他们的更改并通知了适当的方。