哪种流行的“最佳实践”并不总是最好的，为什么？ [关闭]

评论

---

精彩的报价。

– David Thornley
2010-10-26 20:10

---

Raymond Chen引用的下一段可能描述的是匈牙利符号！我看到的大多数公司都没有充分的理由来解释它。

– Craig
2010-10-27 2:03

---

但是，我希望人们不要以此为借口不去查找最佳实践背后的原因。 ;）不幸的是，我见过开发人员有这种态度。

–车
2010-10-27 8:23

---

理由是好的。研究更好。

–琼·普迪（Jon Purdy）
2010-10-27 14:26

---

绝对正确，我之前也说过。也许任何“标准”文档中的第一个标准都应显示为：“为了共享知识并在以后提供废除标准所需的信息，所有标准都应包括其存在的原因。”

–斯科特·惠特洛克
10-10-29在0:47

---

Premature optimization is the root of all evil.

评论

---

+1为强否，不是。

–斯蒂芬
10-10-26在21:26

---

但是，如果您已经意识到某个特定的优化在3％的临界范围内，您是否还为时过早？

–约翰
10-10-26在21:33

---

@罗伯特：那么与“过早的优化是万恶之源”这一说法有何不同？

–约翰
2010-10-26 22:20

---

优化高级设计和技术决策（如语言选择）永远不会为时过早。但是，通常只有在您大部分完成设计后，效率低下才会变得明显，这就是为什么弗雷德·布鲁克斯（Fred Brooks）表示大多数团队无论是否打算都写一个废弃版本。原型的另一个论点。

– Dominique McDonnell
2010-10-27 12:06

---

@ Robert，Knuth的报价过早优化了...

–user1249
2011年1月21日0:00，

---

评论

---

我打算把这个。我爱我一些早期的回报声明。

–卡森·迈尔斯（Carson Myers）
2010年12月1日，下午3:37

---

绝对！人们设计了一些非常有趣的程序流程来避免提早返回语句。深度嵌套的控制结构或连续检查。当if返回确实可以简化此问题时，这确实会使方法膨胀。

–snmcdonald
2010-12-19 22:26

---

如果在一个函数中需要多个返回（除了警卫之外），则您的函数可能太长了。

– EricSchaefer
2010-12-28 20:16

---

除非要在多个位置出现，否则没有return关键字是没有意义的。早点回来，经常回来。它只会进一步简化您的代码。如果人们能够理解中断/继续语句的工作方式，为什么还要为收益而挣扎？

–伊文·普莱斯
2011年1月12日下午16:14

---

我认为这是一个过时的最佳实践。我认为这不是现代的最佳做法。

– Skilldrick
2011年1月17日在11:26

---

评论

---

我曾经发生过这种情况。我建立了自己的ajax网格组件，因为当时没有人可以做我想要的，但是后来用Ext JS网格替换了它。我从一开始就做出了替换显示层的假设，这很有帮助。

– Joeri Sebrechts
2010-10-28 19:15

---

同意如果没有人重新发明轮子，那么我们所有人都将使用木制轮胎驾驶汽车。

–威利博士的学徒
2010-10-29 20:41

---

当我将Boost添加到C ++项目时，我总是感觉像是10％的示例。我总是直接需要少于10％的东西，但是当然我需要导入其他模块的功能，这些模块导入其他模块...

–罗马·斯塔科夫
10 Nov 19 '13：02

---

+1：就在本周，我重新发明了轮子（例如，用适合我们需求且模块化的东西替换使用过时但又流行的jquery插件），并带来了巨大的性能提升。另外，有些人的工作实际上是重塑车轮：以米其林为例，他们从事研发以改进轮胎。

–狂话
2011年1月12日18:39

---

@博士聪明地，这些轮子没有被重新发明，而是被重构了！

–user1249
2011年1月21日，0：01

---

评论

---

我怀疑“一切都进行单元测试”已经成为陈词滥调，就像“过早的优化”报价一样。我通常同意您的比例，并且看到了许多开发人员正在努力模拟应用程序层对象的示例，而这些工作可能更适合进行验收测试。

–罗伯特·哈维（Robert Harvey）
2010-10-26 18:23

---

如果方法结构的更改导致测试更改，则可能是测试做错了。单元测试不应验证实现，而只能验证结果。

–亚当·李尔♦
2010-10-26 18:27

---

@Anna Lear：我认为他是在谈论进行设计/结构更改（重构）。由于设计还不够成熟，因此当您找到更好的设计方法时，您可能不得不修改很多测试方法。我同意，如果您的测试人员技术水平更高，则可能会更容易注意到测试在哪里是个坏主意（由于这个原因和其他原因），但是如果设计不是很成熟，您仍然很可能会在其中进行一些测试。道路。

– n1ckp
10-10-27在0:44

---

我认为这也是为什么“先做测试”的想法行不通的原因。首先要进行测试，您必须具有设计权。但是拥有正确的设计要求您尝试一些事情，看看它们如何工作，以便您可以对其进行改进。因此，您在设计之前就无法真正进行测试，而正确进行设计需要您进行编码并查看其工作方式。除非您有一些真正的超级建筑师，否则我不会真正看到这个想法如何工作。

– n1ckp
2010-10-27 1:02

---

@ n1ck TDD实际上不是设计练习，而是设计练习。这个想法是，您通过测试来改进设计（因为这样可以快速地为您的东西公开一个合理的API），而不是使测试适合现有设计（这可能是不好的/不足的）。因此，您不必先拥有设计权就可以进行测试。

–亚当·李尔♦
2010-10-27 4:45

---

评论

---

同意，当您需要接口（即可以使用的稳定API）时，可以对接口进行编程。

–罗伯特·哈维（Robert Harvey）
10-10-26在20:06

---

在我的阅读中，该规则与语言构造的接口无关。这意味着您在调用类的方法时不应对类的内部工作作任何假设，而应仅依赖于API合同。

– ZsoltTörök
10-10-26在20:52

---

好的，这是一个有趣的问题-我主要是.NET开发人员，所以对我来说，我的界面看起来像IBusinessManager或IServiceContract。对我来说，这非常容易导航（而且我通常将我的界面保留在另一个名称空间（甚至另一个项目）中）。当我使用Java时，实际上发现了这一点令人困惑（通常我看到的接口实现都带有.impl后缀-接口没有描述）。那么这可能是代码标准问题吗？当然，Java中的接口会使代码看起来很混乱-乍一看，它们看上去与普通类完全相同。

–沃森
2010-10-28 14:19

---

@沃森：一个代价是，每当我在Eclipse中的一个方法调用上击中F3（“跳转到声明”）时，我都会跳到该接口，而不是一个实现。然后，我必须控制-T，向下箭头，返回到实现。它还会阻止一些自动重构-例如，您不能在接口定义中内联方法。

–汤姆·安德森（Tom Anderson）
2010-10-28 17:35

---

@汤姆：好吧，先生，我很乐意让您参与这场战争，Eclipse与Intellij。但是，我有出色的道德准则，这使我无法与明显有障碍的人进行身体对抗。繁荣。我并不是说Eclipse不好，而是说如果轴心国使用它来建造或设计他们的战争机器，第二次世界大战现在将被称为“两日混战”。严重的是，我发现它缺乏一些现成的IDE（Intellij / VS + ReSharper）中的润色。我发现自己不止一次与之抗争-太多了。

–沃森
2010-10-29 14:15

---

评论

---

听起来太可怕了……=（不过，我可能在另一方面过分了，我尽可能避免使用M $。

– Lizzan
2010-10-28 13:23

---

那不应该是那样的。应该选择图书馆的价值，而不仅仅是考虑谁创造了它。例如，我喜欢EF，但是我对Enterprise Library的经验很差，并且找到了更好的验证和日志记录工具，例如FluentValidation，log4net和Elmah。

–马特奥·莫斯卡（Matteo Mosca）
2010-10-28 13:28

---

您不会因购买IBM ^ wMicrosoft而被解雇

–克里斯托弗·马汉（Christopher Mahan）
2010-10-29 4:30

---

也有镜像版本，即从不使用任何Microsoft或从不使用任何您需要付费的东西。

–理查德·加兹登（Richard Gadsden）
2011-1-17的12:53

---

我很幸运地在一个组织中工作，而这并不是一个普遍存在的教条，但是在我们采用商业解决方案的地方，肯定会有很多痛苦。当商业解决方案的某些部分无法正常工作时，就会出现问题。当它是开放源代码时，您可以查看源代码（最终文档）并找出问题所在。使用封闭源时，您必须为获得对技术支持知识的特权而付出的特权，而技术支持知识对您所做产品的了解甚至更少。那就是唯一可用的“修复”。

–SingleNegationElimination
2011年1月29日下午6:15

---

评论

---

我无法想象在不利用对象定向提供的组织优势的情况下构建任何规模的软件系统。

–罗伯特·哈维（Robert Harvey）
2010-10-28 20:55

---

罗伯特Unix不是面向对象的，并且可以肯定是合格的软件系统。它似乎也很受欢迎（例如Mac OSX，iPhone，Android手机等）

–克里斯托弗·马汉（Christopher Mahan）
2010-10-29 4:29

---

我的意思是我认为我们应该使用最合适的方法。我已经看到人们使用繁琐且没有多大意义的方法和类，只是因为“它是面向对象的”。那是货物崇拜。

– LennyProgrammers
2010-10-29 7:49

---

没有银弹。在没有面向对象的情况下，函数式编程（Haskell）非常成功。归根结底，您拥有多种工具，为手头的任务选择最佳的分类是您的工作。

– Matthieu M.
2010-11-22 20:46

---

有趣的是，除了使用类，多态性之类的东西外，大多数面向对象的代码实际上都是过程代码。

–奥利弗·韦勒
2010年11月30日，0：05

---

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

评论

---

所有代码都应该可以理解。注释是其中的主要工具，但远非唯一。

–旅行
2011年1月17日22:27

---

绝对地，代码应该是可以理解的。但是没有唯一的理由写一个注释，该注释不会为方法名称添加任何内容。如果写/ **设置等级。 * / void setRank（int rank）{this.rank = rank;我认为评论是愚蠢的。为什么要写？

–弗拉基米尔·伊万诺夫（Vladimir Ivanov）
2011年1月17日在22:34

---

生成的文档。这就是/ ** * /格式的含义，而不是/ * * /格式的注释。或.NET，它将是///

–贝琳·洛里奇（Berin Loritsch）
2011年1月18日下午16:19

---

使用} // end，} // end，} // end while是我见过的浪费评论的最佳示例。我已经看过很多次了，开头括号不超过2行。恕我直言，如果您需要这些注释，则您的代码需要重构...，或者您需要付20美元并购买一个IDE / Text编辑器，以突出显示匹配的花括号。

–scunliffe
2011年1月21日，11：54

---

代码说“如何”。评论需要说“为什么”。

–user1249
11年1月27日在18:03

---

评论

---

有趣。我在一定程度上同意。在最后一部分中：称呼您想要的东西，它们就是助记符，仅此而已。

–史蒂文·埃弗斯（Steven Evers）
2010-11-29 21:38

---

+1 ...您是对的，很难认真对待。 <大声的声音> *我是SCRUMMASTER *

–GrandmasterB
2010-11-29 21:50

---

和寓言。它让我想起教堂的讲道，或自助大师（和喜剧演员）闻名的轶事：“带我的朋友史蒂夫。史蒂夫一直在与妻子谢丽尔吵架。那两个人会花几个小时，直到他们的婚姻处于真正的危险之中。然后，有一天……”这些说教的纱线不会在其他领域打扰我，但我讨厌看到它们在工程科学中激增。

–evadeflow
2010-11-29 22:02

---

Scrum忍者呢？

–贝琳·洛里奇（Berin Loritsch）
2011年1月12日在18:20

---

我不同意“猪和鸡”的比较……它直接面对敏捷宣言。即“基于合同谈判的客户协作”。在项目成功方面，客户与项目团队一样被授予（如果不是更多的话）。称某些角色为“猪”而其他角色为“鸡”则树立了“我们与他们”的思想，即恕我直言是成功项目的最大障碍。

–迈克尔·布朗（Michael Brown）
2011年1月21日在23:58

---

评论

---

过早的优化是万恶之源。与无法维护的代码相比，慢速代码在现实生活中仅是极少出现的问题。使用ORM，然后仅在需要时切入抽象。

– Fishtoaster
2010-10-26 18:12

---

ORM是80-20工具。他们的目的是要处理80％的CRUD，以至于过一会儿再写所有无尽的管道代码就变得很累。剩下的20％可以通过使用存储过程和编写普通SQL查询等“常规”方式来完成。

–罗伯特·哈维（Robert Harvey）
2010-10-26 18:13

---

@Fishtoaster：您的意思不是说：“我们应该忘记效率低下的问题，大约有97％的时间是这样：过早的优化是万恶之源。但是，我们不应该在这3％的临界水平上放弃机会。”

–罗伯特·哈维（Robert Harvey）
2010-10-26 18:15

---

@Robert Harcey：我没有使用直接引号是有原因的。我认为大多数程序员都过于关注效率问题，这是他们中很少真正需要解决的问题。诚然，在某些领域中，它比其他领域更重要，但是可维护性和可扩展性到处都是问题。另一个修改过的语录：“使其生效，使其可维护，使其易于阅读，使其具有可扩展性，使其可测试，然后，如果有时间，事实证明您需要它，则使其快速。”

– Fishtoaster
2010-10-26 18:23

---

@克雷格：你怎么不承认你的陈述中的讽刺？需要一年的时间来学习如何从ORM中获得良好的性能，这是反对ORM的一个极好的理由，因为需要“控制” SQL生成并注入存储过程。如果您有足够的知识，则可以完全绕过ORM。

–尼古拉斯·奈特
2010-11-22在11:48

---

Draw_Foo()
Write_Foo()
Create_Foo()

Foo_Draw()
Foo_Write()
Foo_Create()

评论

---

大概和在TM的功能列表中键入Foo一样容易。

–乔什·K（Josh K）
2010-10-26 17:50

---

听起来您实际上希望它是Foo.Draw（），Foo.Write（）和Foo.Create（），以便可以执行Foo.methods.sort或Foo.methods.grep（[我追求的目标] ）。分类

– Inaimathi
2010-10-26 17:59

---

以“ Get”开头是另一个示例。

– JeffO
2010-10-26 18:25

---

我来自Objective-C世界，在做Java时（我的另一生）非常想念冗长的方法名和中缀表示法。自从代码完成开始工作以来，我也没有发现额外的键入问题。

–user4051
2010-10-26 18:28

---

@Scott Whitlock：对于某些.NET开发人员来说，iirc，VS 2008并没有做到这一点。不过2010年确实如此，这真是太棒了。

–史蒂文·埃弗斯（Steven Evers）
10 Nov 18 '21：44

---

评论

---

我已经在ASP.NET和ASP.NET MVC中完成了Web开发，尽管MVC似乎很简陋，但由于许多原因，我还是更喜欢ASP.NET，这有很多原因：简单性，可维护性和对标记的极好的控制。一切都有它的位置，尽管看起来有些重复，但维护起来却是一种快乐。它是完全可定制的，因此，如果您不喜欢开箱即用的行为，则可以对其进行更改。

–罗伯特·哈维（Robert Harvey）
2010-10-29 6:06

---

就OO而言，有好的方法也有坏的方法。继承被高估了，并且在现实世界中使用的程度比大多数人认为的要少。即使在面向对象的世界中，目前也存在着一种趋向于更加实用，一成不变的开发风格的趋势。

–罗伯特·哈维（Robert Harvey）
2010-10-29 6:08

---

+1代表提及MVC。尽管MVC的概念（将数据层逻辑，表示逻辑和背景逻辑分开）是一个好主意，但是将它们物理地分成一个复杂的文件夹层次结构，其中包含代码片段的文件杂乱无章，这是愚蠢的。我将整个现象归咎于PHP缺乏名称空间支持，而新手开发人员将数十年的技术赞誉为“最新的东西”。很简单，为数据库访问器，GUI和后台逻辑创建名称空间（以及需要时的子名称空间）。

–伊文·普莱斯
2010年11月19日在18:50

---

对于OO，直到您的项目发展到管理复杂性变得重要的规模时，您才真正看到它的好处。尽可能遵循单一责任原则，并且如果可以公开访问您的代码（例如，.dll），请在任何可能的地方隐藏类/方法/属性的内部实现，以使代码更安全并简化API。

–伊文·普莱斯
2010年11月19日在18:55

---

我个人认为shape-> rectangle-> square示例是反对oop的最优雅的论据之一。例如，对于Square（10）.Draw（）来说，Rectangle（10，10）.Draw（）就足够了。所以我想这意味着Square是矩形的子类。但是mySquare.setWidthHeight（5,10）是胡说八道（即，它不符合Liskov替换原理），正方形不能具有不同的高度和宽度，尽管矩形可以，因此这意味着矩形是正方形的子类。在其他情况下，这称为“圆，椭圆问题”

–SingleNegationElimination
2011年1月19日在2:32

---

评论

---

我同意YAGNI，但我明白您的意思。 YAGNI的重点是与想要从头到尾计划所有细节的人员打交道。尽管十分之九，但它却被用作借用工程师代码或完全跳过计划的借口。

–杰森·贝克（Jason Baker）
2010-11-29 19:55

---

P.Floyd，@ Jason Baker：+1完全正确。俗话在这里适用：“在实验室工作数月可节省图书馆时间”

–史蒂文·埃弗斯（Steven Evers）
2010-11-29 21:40

---

规范通常会（而且大多数情况下应该）保留大多数实现，并且某些接口是开放的。规范中没有直接列出的所有内容，而是实现规范所需的所有内容，无论是实现决策，用户可见的界面还是其他任何内容，也都是规范的间接要求。如果某个功能不在规范中，并且未在规范中隐含，那么您就不需要它。这怎么会令人困惑？

–SingleNegationElimination
11年1月28日在14:01

---

@TokenMacGuy的关键方面是规范部分所隐含的内容。那是意见分歧很大的地方。

–塞恩·帕特里克·弗洛伊德（Sean Patrick Floyd）
11年1月28日在14:04

---

评论

---

＃2是最佳做法？

– Hogan
2010-10-27 3:35

---

@Hogan：是的，它在许多地方都有记录vyaskn.tripod.com/sql_server_security_best_practices.htm和flylib.com/books/en/3.404.1.34/1在这里很少：simple-talk.com/community/blogs/tony_davis/存档/ 2009/08/06 /…

– gbn
2010-10-27 3:57

---

@Hogan：仅镜像基本表的视图不会增加直接使用基本表的安全性。如果您连接到securityuser表，或者掩盖了某些列，那么就足够了。但是从表或视图中选择每一列：没有区别。就我个人而言，我还是使用存储过程。

– gbn
10-10-27在11:20

---

@Hogan：我对SQL Server有所了解：-) stackoverflow.com/users/27535/gbn我的意思是，如果视图是SELECT * FROM TABLE，则表上的GRANT SELECT与GRANT SELECT ON VIEW没有区别

– gbn
10-10-27在11:42

---

@gbn：我同意。那里没有区别。我想我们可能会说同样的话。我想我最初的评论（“＃2是最佳实践吗？”）更多地基于我的个人经验，即视图（如触发器）经常被误用而不是正确使用。因此，这种最佳做法只会导致滥用，而不会导致滥用。如果它被认为是一种最佳实践，那么您100％正确，那就不好了。

– Hogan
2010-10-27 22:53

---

评论

---

+1我仍然看不到设计模式是美观还是优雅的解决方案。它们是针对语言缺陷的解决方法，仅此而已。

–奥利弗·韦勒
2010-11-30 0:02

---

只是将其视为使用语言本身消除语言气味的一种尝试。

–FilipDupanović
2011年1月18日，下午2:10

---

评论

---

听起来有人在工作中得了“发烧”，或者在这种情况下是“原理发烧”。列表类不违反SRP。它的所有功能都有一个目的，即操纵对象的集合。在班上只有一个功能听起来对我来说太过分了。 SRP背后的原理是，一个代码单元（无论是方法，类还是库）都应具有单一职责，可以简明地表述。

–迈克尔·布朗（Michael Brown）
2011年1月22日，0：37

---

我开始从那些发现不可能编写纯粹的纯函数代码的人那里看到这种疯狂。太多的教育使世界上的每个问题都可以从一本模式书中解决。关于实用主义的想法还不够。像您一样，我已经看到了一些基于类的OO代码，它们是如此可怕，以至于完全不可能遵循它。而且它巨大而肿。

–quickly_now
2011年2月6日在9:51

---

在这里第二条评论。许多“原则”被过度应用。很多事情都是好主意，有时恰恰相反是合适的。好的程序员知道什么时候打破规则。因为这些规则不是“规则”，所以它们是“大多数时候的良好做法的陈述，除非它是一个愚蠢的想法”。

–quickly_now
2011-2-6在9:53

---

“想象一下，.Net API的创建者是否有这种想法：我们将拥有ListSorter，ListReverser和ListSearcher类，而不是List.Sort（），List.Reverse（），List.Find（）等。 ！”。这正是在C ++中完成的工作，非常好。这些算法与数据结构是分开的，因此，如果我编写自己的容器，则所有与标准库一起使用的算法都将与我的新容器一起使用。它在.Net领域中必须是可怕的，为要排序的每个新容器编写了一个新的排序功能。

– Mankarse
2011-10-26 12:14

---

0 == memberArray.length

isEmpty()

return null != memberArray ? 0 == memberArray.length : true;

评论

---

我很少将此视为问题。通常，这是因为我通常在一种方法中看到的太多而不是很少。但是，根据某些研究，方法的极低复杂度也比中等程度的低复杂度具有更高的错误率。 enerjy.com/blog/?p=198

– MIA
2010-10-27 15:30

---

是的，这绝对只是Clean Code中的问题。正如您所说，在现实生活中方法往往太长。但有趣的是看到那条曲线！确实，应该使事情尽可能简单，但不要简单。

–乔纳斯·普拉卡（Joonas Pulakka）
2010-10-27 16:16

---

我发现您的第二个示例更具可读性，并且如果要公开它，则必须使用该格式（或类似的名称，例如类本身的Length属性）。

–罗伯特·哈维（Robert Harvey）
2010-10-27 22:13

---

@Robert Harvey：第二个示例是一个很好的公共方法，但是从类本身内部调用它是有问题的，因为在了解如何实现之前您并不确切知道它的作用。例如，它可以检查是否为空。请参阅上面的内容。

–乔纳斯·普拉卡（Joonas Pulakka）
10-10-28在5:58

---

@乔纳斯：足够公平。

–罗伯特·哈维（Robert Harvey）
10-10-28在21:08

---

评论

---

自我记录代码绝对不错。虽然，我喜欢在注释旁边加上简单的计算（以表示返回类型或返回值是什么）。但是，如果您的注释需要比代码本身更多的单词，那么可能是时候重写代码了。

– sova
2010-11-29 20:11

---

我必须同意sova提出这一建议的方式。干净的代码胜于注释。

–riwalk
2010-11-29 23:47

---

您仍然需要其中的“为什么”！

–user1249
2011年1月21日，0：04

---

我宁愿评论解释原因。这意味着当我查看代码意图时，我不得不减少对反向代码意图的思考。

–quickly_now
2011年1月21日，1：17

---

评论

---

我正在进行九年的编程，没有一个goto语句（如您所述，包括多个状态机）。将您的想法扩展到新的想法。

–riwalk
10-11-22在4:46

---

@Mathieu M.-同意-将GOTO与结构化控制语句混合是不明智的。 （这是纯C语言，这不是问题。

– MZB
10 Nov 25'0:22

---

@ Stargazer2-使用简单的FSM，它取决于是否将状态放入变量中并将其用作调用过程的索引（与计算出的GOTO是否相同？）是否比使用程序计数器提供了更清晰/更快的代码作为FSM状态。我并不是在大多数情况下都主张将其作为最佳解决方案，而在某些情况下仅是最佳解决方案。将您的想法扩展到其他方法。

– MZB
10 Nov 25'0:31

---

@MZB，您是否同意函数调用也只是计算得出的GOTO？同样，for / while / if / else / switch构造也适用。语言设计人员出于某种原因将直接更改抽象到程序计数器。不要使用goto。

–riwalk
2010-11-29 22:37

---

直接实现状态机可能是一种反模式。在没有字面表示状态和过渡的情况下，有很多方法可以拥有状态机。例如，导入重新

–SingleNegationElimination
2011年1月19日，下午2:37

---

评论

---

我猜您从未听说过TypeMock吗？它允许模拟类，私有，静态（工厂）等任何东西。

– Allon Guralnek
2011年1月20日23:16

---

@Allon：我有，但是它并不是免费的，这对于大多数人来说不是一个选择。

– BlueRaja-Danny Pflughoeft
2011年1月20日23:30

---

如果您必须编写许多工厂类，那么您在做错什么。智能DI库（例如C＃的Autofac）可以将Func ，Lazy ，Delegates等用于工厂，而无需自己编写任何样板文件。

– Gix
2011-2-22 15:01

---

评论

---

+1，听起来像是我最后就业的最细微之处！我原则上尊重分层应用程序，但是在没有意义时，太多的人将其视为灵丹妙药。大多数业务软件的业务逻辑量极低，其功能相对简单。这会使分层业务逻辑成为样板代码的噩梦。很多时候，数据查询和业务逻辑之间的界限可能会变得模糊，因为查询就是业务逻辑。

– Maple_shaft♦
2011年6月23日12:42

---

……此外，大多数商店绝对无法识别UI逻辑或Presentation逻辑。因为他们不了解典型的CRUD应用程序中几乎没有多少业务逻辑，所以当他们的大多数逻辑作为表示逻辑驻留在表示层时，他们会觉得自己必须做错了。它被错误地标识为业务逻辑，然后人们将其推到服务器以进行另一个服务器调用。瘦客户端可以并且应该具有表示逻辑，例如。 （如果在dropDown3中选择了option1，则隐藏textField2）。

– Maple_shaft♦
2011年6月23日12:46

---

评论

---

@Or__ ___启用Nice GWB逻辑是邪恶的角度。因此，您讨厌hScroll，您是否有任何合理的理由将col-width限制为80个字符？为什么不160或256？我认为我们都可以假设大多数开发人员已经淘汰了他们的VT220终端，并用puTTY替换了它们，因此他们无论如何都可以通过编程方式扩展宽度。

–伊文·普莱斯
2011年1月18日，下午1:38

---

我更喜欢我们坚持80个字符的限制。您给我更多的水平空间后，我将尝试与其他文件并排打开其他文件。我讨厌必须滚动四种方式。另外，我经常注意到我被迫使用80个字符的上限编写更具可读性的代码。

–FilipDupanović
2011-1-18的2:17

---

您将如何打印？

–user1249
2011年1月21日，0：11

---

抱歉-必须对此表示不同意见。我真的很讨厌长长的线-它需要更多的眼睛移动，它需要鼠标手势滚动，它很难看到行尾的微妙的晃动的东西。在大约99％的情况下，有一些干净的方法可以使内容跨几行（更短）运行，这更清晰，更易于阅读。 80个字符可能是任意的，并且“因为在打孔卡时代就是这样”，但由于上述原因，在大多数情况下，它仍然是一个合理的工作框架。

–quickly_now
2011年1月21日，在1:25

---

缩进2个空格。并使用带有自动缩进跟踪器的编辑器。多年来，我一直这样做，没什么大不了的。 （具有正确模式的Emacs在这里有帮助。）

–quickly_now
2011年2月6日上午9:47

---

评论

---

我有一位需要camelCase的老师，因为他坚持这是人们在现实世界中使用的东西...同时，我在工作时在两个不同的小组中进行编程-两个小组都坚持使用under_scores。重要的是您的小组使用什么。他本可以将自己定义为首席程序员，但在我的书中，一切都会好起来的-我们遵循他的惯例-但他始终将自己的观点视为“现实世界中的工作方式”，就好像没有其他有效的方法一样。道路。

–xnine
2010-11-30 4:42

---

@xnine我在该网站上没有足够的代表来评价您的评论，因此，我将以同意的评论进行回复。

– Maxpm
2010-11-30 4:44

---

驼峰式大小写（首字母小写）和帕斯卡大小写（大写的每个单词的首字母）都是很常见的约定。在大多数语言中，camelCase用于私有/内部变量，而PascalCase用于类，方法，属性，名称空间，公共变量。习惯于为可能使用不同命名方案的项目做好准备并不是一个坏习惯。

–伊文·普莱斯
2011年1月12日在16:18

---

仅供参考。一些语言根据变量的首字母是否大写来推断含义。在这种语言中，如果第一个字母为大写字母，则将变量视为常量，任何对其进行更改的尝试都会引发错误。

–贝琳·洛里奇（Berin Loritsch）
2011年1月12日在18:28

---

在Go中，公共方法和类中的成员以大写字母开头；带有小写字母的私人字母。

–乔纳森·莱弗勒（Jonathan Leffler）
2011年1月18日14:39

---

评论

---

那是一堆负面因素，使我对您对单身人士的实际立场感到困惑。

–Paul Butcher
2010-11-30在11:17

---

@Paul Butcher：我讨厌单身人士，永远不应该使用它

–user2528
2010年12月1日，7：58

---

@rwong：就我个人而言，我认为没有任何理由是合法的。只需将其编写为普通班级即可。确实，除了懒惰之外，没有任何理由使用单身人士来提倡不良习惯或设计。

–user2528
2010年12月1日于22:23

---

谁说使用Singeltons是最佳做法？

–菲尔·曼德（Phil Mander）
2010-12-10在0:29

---

单例确实有其位置，尤其是在启动时分配并填充了操作结构的情况下，然后基本上在整个程序运行时才变为只读。在那种情况下，它只是变成了指针另一侧的缓存。

– Tim Post
2010-12-10 8:06

---

评论

---

好吧，现在我很好奇-为什么这么说？我有点傻-您可以提供一些代码示例来备份您的语句吗？

– Paul Nathan
2010-12-10 3:22

---

@Paul Nathan：就越野车而言，这是一个示例：for（unsigned int i = 0; i <10; i ++）{int crash_here = my_array [max（i-1,0）];}

– AareP
2010-12-10 5:59

---

@AareP：可以肯定的是-我假设您引用的事实是，当将无符号整数0减1时，您实际上最终会获得无符号整数可能存储的最大正值吗？

–亚当·佩恩特（Adam Paynter）
2010-12-10 10:11

---

@Adam Paynter：是的。对于c ++程序员来说，这似乎很正常，但是让我们面对现实吧，“ unsigned int”是正数的一种不好的“实现”。

– AareP
2010-12-10 11:19

---

在小型嵌入式计算机上不是一个好主意-经常使用无符号int会生成更小，更快的代码。取决于编译器和处理器。

–quickly_now
2011年1月21日，1：19

---

评论

---

这个。我曾经将一个长函数重构为几个，只是意识到几乎所有函数都需要原始代码的几乎所有参数。参数处理非常痛苦，以至于回到旧代码更容易。

–l0b0
2011-1-17 14:59

---

我认为对此有一个反论点，那就是将大型方法的各个部分重构为单独的调用可以使大型方法更易于阅读。即使该方法仅被调用一次。

–杰里米·海勒（Jeremy Heiler）
2011-1-17的15:33

---

@Jeremy怎么样？与仅在一行代码段中描述一行代码的顶部放置一行注释相比，抽象出一段代码并将其放在自己的方法中如何使代码更具可读性？假设该代码块在该代码段中仅使用一次。对于大多数程序员来说，在阅读代码时分解代码的工作部分和/或放置一些单行注释以提醒他们如果不能做的话真的难吗？

–伊文·普莱斯
2011-1-18的1:28

---

@Evan：将代码段有效地放入函数中可以为其命名，希望很好地解释该代码段的作用。现在，无论该代码段被调用到哪里，您都可以看到名称来解释代码的作用，而不必分析和理解算法本身。如果做得好，这可以极大地简化阅读和理解代码的过程。

–sbi
2011年1月19日19:00

---

+1，如果可以的话，我会付出更多。单个函数中有1000行代码的C代码块没有任何问题（例如，带有大型switch（）的解析器），其目的是明确而简单的。淘汰所有小片段并称呼它们只会使事情变得更难以理解。当然，这也有局限性。明智的判断就是一切。

–quickly_now
2011年1月21日，下午1:22

---