这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
异常应该只在真正异常的情况下使用
在我最近参与的项目中，异常的使用似乎非常猖獗。
这里有一个例子:
我们有拦截网络请求的过滤器。筛选器调用筛选器，筛选器的任务是检查请求是否具有某些输入参数并验证这些参数。你设置了要检查的字段，并且抽象类确保参数不为空，然后调用一个由你的特定类实现的screen()方法来进行更多的扩展验证:
public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{
//
if (!checkFieldExistence(req)){
return false;
}
return screen(req,resp,filterConfig);
}
checkFieldExistance(req)方法从不返回false。如果所有字段都不缺少，则返回true，如果缺少字段则抛出异常。
我知道这是一种糟糕的设计，但部分问题在于，这里的一些架构师认为，每次遇到意外情况时都需要抛出异常。
此外，我知道checkFieldExistance(req)的签名确实抛出了一个异常，这只是我们几乎所有的方法都这样做-所以我没有想到这个方法可能会抛出一个异常而不是返回false。直到我翻遍代码才发现。
其他回答
方法/函数参数的先决条件应该是语言的一部分，而不是程序员总是检查它。
生成的文档几乎总是毫无价值的。
或者，作为一个推论:您的API需要为维护者和用户提供单独的文档集。
实际上有两类人需要了解您的API:维护者，他们必须了解您的实现的细节，以便有效地完成工作;用户，他们需要高级的概述、示例和关于他们所访问的每个方法的效果的详细细节。
我从未遇到过在这两个方面都成功的生成文档。通常，当程序员为工具编写注释以提取和生成文档时，他们的目标是介于两者之间的某个地方——刚刚足够的实现细节让用户感到厌烦和困惑，但不足以显著帮助维护者，并且没有足够的概述对用户有任何真正的帮助。
As a maintainer, I'd always rather have clean, clear comments, unmuddled by whatever strange markup your auto-doc tool requires, that tell me why you wrote that weird switch statement the way you did, or what bug this seemingly-redundant parameter check fixes, or whatever else I need to know to actually keep the code clean and bug-free as I work on it. I want this information right there in the code, adjacent to the code it's about, so I don't have to hunt down your website to find it in a state that lends itself to being read.
As a user, I'd always rather have a thorough, well-organized document (a set of web pages would be ideal, but I'd settle for a well-structured text file, too) telling me how your API is architectured, what methods do what, and how I can accomplish what I want to use your API to do. I don't want to see internally what classes you wrote to allow me to do work, or files they're in for that matter. And I certainly don't want to have to download your source so I can figure out exactly what's going on behind the curtain. If your documentation were good enough, I wouldn't have to.
无论如何，这就是我的看法。
不要太担心学习什么语言，使用业界重量级的语言，如c#或python。像Ruby这样的语言在卧室里很有趣，但在工作场合就没什么用了。像c#和Java这样的语言可以处理小到非常大的软件项目。如果有人不这么认为，那么你谈论的是脚本语言。期!
在开始一个项目之前，要考虑网络上有多少支持和代码示例。再次强调，选择像Ruby这样的语言，与Java相比，Ruby的代码样本在网络上非常少，这只会让你在遇到问题时更加痛苦。
当你的老板问你的代码写得怎么样的时候，你不能在论坛上发了一条消息就指望得到答复。你要说什么?“我在这个论坛上等着有人来帮我”
学习一门语言，并学好它。学习多种语言可能会带来技能和实践，但你甚至只能掌握所有语言。擅长其中一项。有一整本专门讲Java中的线程的书，仔细想想，它只是100多个命名空间中的一个。
精通一门或精通许多门。
前期设计——不要因为兴奋而开始写代码
我见过很多设计糟糕的应用程序，因为开发人员太兴奋了，以至于他们直接打开白页开始写代码。我知道在开发生命周期中事情会发生变化。但是，如果应用程序具有多种不同的布局和开发方法(从一种形式到另一种形式，从一种方法到另一种方法)，则很难处理这些应用程序。
如果没有明确定义任务以及计划如何编写任务，就很难达到应用程序要处理的目标。花点时间(而不是仅仅5分钟)，确保在开始编码之前，你已经尽可能多地布局了它。这样你就可以避免顶替你的人不得不承担的意大利面条般的混乱。
代码就是设计
