这绝对是主观的,但我想尽量避免它变成争论。我认为如果人们恰当地对待它,这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上,但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么,你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如,大括号放置),但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点,不管你是否恰好同意这些观点。
关系数据库是在浪费时间。改用对象数据库!
关系数据库供应商试图欺骗我们,让我们相信世界上唯一可扩展的、持久的和安全的存储就是关系数据库。我是一个认证的DBA。你是否曾经花了几个小时试图优化一个查询,却不知道哪里出了问题?关系数据库不允许您在需要时创建自己的搜索路径。你把应用速度的控制权拱手让给了素未谋面的人,他们并不像你想象的那么聪明。
当然,有时在维护良好的数据库中,他们会为复杂的查询提供快速答案。但你为此付出的代价太高了!每次要读取数据项时,都必须选择编写原始SQL,这是很危险的。或者使用Object关系映射器,这会增加更多的复杂性和超出你控制的事情。
更重要的是,你被禁止提出智能搜索算法,因为每次该死的往返数据库花费你大约11毫秒。这太过分了。想象一下,您知道这个超级图算法,它将回答一个特定的问题,这个问题甚至可能无法用SQL表达!,在适当的时候。但是,即使您的算法是线性的,而有趣的算法不是线性的,也不要将它与关系数据库结合起来,因为枚举一个大表将花费您数小时!
将其与SandstoneDb或Gemstone for Smalltalk进行比较!如果你喜欢Java,试试db4o吧。
因此,我的建议是:使用对象- db。当然,它们并不完美,有些查询速度会比较慢。但是你会惊讶的发现很多人会更快。因为加载对象不需要在SQL和域数据之间进行所有这些奇怪的转换。如果您确实需要某个查询的速度,对象数据库有您应该信任的查询优化器:您的大脑。
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.
我得到的好处是,我不必不断地处理那些因为我碰巧以某种方式破坏了它而不再工作的软件,并试图找出停止工作的原因和原因。
扩展方法是魔鬼的工作
Everyone seems to think that extension methods in .Net are the best thing since sliced bread. The number of developers singing their praises seems to rise by the minute but I'm afraid I can't help but despise them and unless someone can come up with a brilliant justification or example that I haven't already heard then I will never write one. I recently came across this thread and I must say reading the examples of the highest voted extensions made me feel a little like vomiting (metaphorically of course).
主要原因是增加了可读性、改进了oo性以及更好地连接方法调用的能力。
I'm afraid I have to differ, I find in fact that they, unequivocally, reduce readability and OO-ness by virtue of the fact that they are at their core a lie. If you need a utility method that acts upon an object then write a utility method that acts on that object don't lie to me. When I see aString.SortMeBackwardsUsingKlingonSortOrder then string should have that method because that is telling me something about the string object not something about the AnnoyingNerdReferences.StringUtilities class.
LINQ是这样设计的,链式方法调用是必要的,以避免奇怪和不舒服的表达式,来自LINQ的扩展方法是可以理解的,但一般来说,链式方法调用降低了可读性,并导致我们在混乱的Perl竞赛中看到的那种代码。
因此,简而言之,扩展方法是邪恶的。摆脱撒旦的枷锁,致力于自由扩展代码。
观点:大多数代码都很糟糕,因为这是程序员想要的。
间接地,我们一直在培育一种极具创造力的文化。这并不是说我不认为解决问题具有创造性元素——它确实存在——只是它与绘画之类的事情根本不一样(参见保罗·格雷厄姆的著名文章《黑客和画家》)。
If we bend our industry towards that approach, ultimately it means letting every programmer go forth and whack out whatever highly creative, crazy stuff they want. Of course, for any sizable project, trying to put together dozens of unrelated, unstructured, unplanned bits into one final coherent bit won't work by definition. That's not a guess, or an estimate, it's the state of the industry that we face today. How many times have you seen sub-bits of functionality in a major program that were completely inconsistent with the rest of the code? It's so common now, it's a wonder anyone cause use any of these messes.
复杂,复杂,丑陋的东西只会变得更糟,更不稳定。如果我们正在建造一些实体的东西,地球上的每个人都会说我们的东西是多么丑陋和糟糕,但由于它或多或少被虚拟隐藏起来,我们能够逃脱一些我们物种所见过的最糟糕的制造过程。(你能想象一辆车有四个不同的人用四种不同的方式设计了四个不同的轮子吗?)
但可悲的是,这一切中有争议的部分是,绝对没有理由这样做,除了历史上的文化倾向于更多的自由和更少的组织,所以我们保持了这种方式(可能变得更糟)。软件开发是一个笑话,但它是一个笑话,因为这是程序员想要的(但永远不会承认这是真的,“管理层的阴谋”对大多数人来说是一个更好的理由)。
我们还会搬起石头砸自己的脚多久,才会幡然醒悟,意识到我们才是握着枪、指着枪、扣动扳机的人?
保罗。