这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
使软件可配置是一个坏主意。
可配置软件允许最终用户(或管理员等)选择太多的选项，这些选项可能没有一起测试过(或者，如果有超过非常小的数量，我可以保证没有测试过)。
因此，我认为将配置硬编码(但不一定回避常量等)为JUST WORK的软件是一个好主意。使用合理的默认值运行，并且不允许更改它们。
一个很好的例子是谷歌Chrome上的配置选项的数量-然而，这可能仍然太多:)
其他回答
你并不总是需要数据库。
如果需要存储的“东西”少于几千个，而且不需要锁定，平面文件可以工作，而且在很多方面都更好。它们更便于携带，你可以在必要时手动编辑它们。如果你在数据和业务逻辑之间有适当的分离，你可以很容易地用数据库替换平面文件，如果你的应用程序需要它。如果您在设计时考虑到这一点，它就会提醒您在数据和业务逻辑之间进行适当的分离。
-- bmb
开发团队应该更多地按照技术/架构层而不是业务功能来划分。
我来自一个开发者拥有“从网页到存储过程的一切”的普遍文化。因此，为了在系统/应用程序中实现一个功能，他们将准备数据库表模式，编写存储procs，匹配数据访问代码，实现业务逻辑和web服务方法，以及web页面接口。
And guess what? Everybody has their own way to doing things! Everyone struggles to learn the ASP.NET AJAX and Telerik or Infragistic suites, Enterprise Library or other productivity and data layer and persistence frameworks, Aspect-oriented frameworks, logging and caching application blocks, DB2 or Oracle percularities. And guess what? Everybody takes heck of a long time to learn how to do things the proper way! Meaning, lots of mistakes in the meantime and plenty of resulting defects and performance bottlenecks! And heck of a longer time to fix them! Across each and every layer! Everybody has a hand in every Visual Studio project. Nobody is specialised to handle and optmise one problem/technology domain. Too many chefs spoil the soup. All the chefs result in some radioactive goo.
Developers may have cross-layer/domain responsibilities, but they should not pretend that they can be masters of all disciplines, and should be limited to only a few. In my experience, when a project is not a small one and utilises lots of technologies, covering more business functions in a single layer is more productive (as well as encouraging more test code test that layer) than covering less business functions spanning the entire architectural stack (which motivates developers to test only via their UI and not test code).
Variable_Names_With_Bloody_Underscores
或者更糟
CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES
应该在全球范围内清除……与偏见!CamelCapsAreJustFine。 (全局常数不承受)
GOTO语句仅供11岁以下的开发人员使用
任何不支持指针的语言都名不副实
.Net = .Bloat 微软网站开发的最佳范例(无表情web 2) 是缓慢膨胀的最好的例子cr@pw@re曾经写过。 (可以试试Web Studio)
回应: 好的，让我来谈谈下划线的问题。从你提供的C链接:
-全局常量应该全部大写，用“_”分隔符。 我实际上同意这一点，因为这太明显了
-以NetworkABCKey为例。注意ABC中的C和调音中的K是如何混淆的。有些人不介意这一点，有些人只是讨厌它，所以你会在不同的代码中发现不同的策略，所以你永远不知道该如何调用某个东西。
我属于前者。我选择名字非常谨慎，如果你不能一眼看出K属于Key，那么英语可能不是你的第一语言。
C函数名 在c++项目中应该有很少的C函数。 对于C函数，使用GNU约定的所有小写字母，以'_'作为单词分隔符。
的理由
* It makes C functions very different from any C++ related names.
例子
int some_bloody_function () ｛ ｝
这些“标准”和惯例只不过是随时间而传下来的任意决定。我认为，虽然它们有一定的逻辑意义，但它们使代码变得混乱，使一些本应简短而易于阅读的东西变得笨拙、冗长和混乱。
C被采纳为事实上的标准，不是因为它友好，而是因为它无处不在。我可以用一种语法友好的高级语言用20行代码编写100行C代码。
这使得程序流易于阅读，并且我们都知道，在一年或更长时间后重新访问代码意味着要到处跟踪面包屑。
我确实使用下划线，但只对全局变量，因为它们很少，而且它们很明显。除此之外，一个经过深思熟虑的CamelCaps()函数/变量名还没有让我失望!
C(或c++)应该是第一种编程语言
第一语言不应该是简单的，它应该是建立学生的思想，为严肃的计算机科学做准备的语言。 C语言是完美的，它迫使学生考虑内存和所有低级别的东西，同时他们可以学习如何构造代码(它有函数!)
c++有一个额外的优势，它真的很糟糕:)这样学生就会明白为什么人们必须想出Java和c#
大多数“用户友好”的第四代语言(包括SQL)都是毫无价值的、被高估的垃圾，不应该被广泛使用。
4gl通常有一个冗长和模糊的语法。尽管4gl应该允许“非技术人员”编写程序，但你仍然需要“技术人员”来编写和维护它们。
一般来说，4GL程序更难编写，更难阅读，更难优化。
应该尽量避免使用4gl。
