您怎么知道您正在编写好的代码？ [重复]

#1 楼

对我来说，最大的提示是：

当您不得不返回并添加/修改功能时，会很难吗？进行更改时，是否会不断破坏现有功能？

如果以上回答是“是”，则您的总体设计可能不佳。

（对我来说）至少）在需要对更改做出响应之前很难判断一个设计（当然，这是出于一定理由；有些代码很糟糕，您可以马上说出来，但这甚至是有经验的。）

#2 楼

这肯定是我工作的标准方法。




哪扇门代表您的代码？哪个门代表您的团队或您的公司？我们为什么在那个房间里？这仅仅是正常的代码审查，还是上线后不久我们发现了一系列可怕的问题？我们是否在恐慌中进行调试，仔细研究我们认为可行的代码？是客户成群结队而经理们垂涎三尺吗...


（罗伯特·C·马丁（Robert C Martin），清洁规范-上图打开的书）

#3 楼

您知道您在以下情况下正在编写良好的代码：


事情很聪明，但不太聪明
算法在速度和可读性上都是最佳的
类，变量和函数都很好地命名并且有意义，而不必考虑太多
，您可以在周末休假后回到它，并且可以直接跳转
可以重复使用的事物是可重复使用的
单元测试易于编写

#4 楼

尽管您说您没有其他编码人员可以这样做，但是为了别人的方便，我将其包括在内。

代码质量测试：让另一个从未看过代码的程序员阅读该代码，以解释每个模块对您的影响。您跳入并解释某些内容的渴望越强烈，代码可能就越糟糕。如果您可以张着嘴平静地坐在那里，而他们不需要问很多问题，那么您可能很好。

为了您的利益，这里有一些关于何时不使用的一般指导原则不能有同龄人。它们不是绝对的，只是“闻起来”。

好兆头


方法往往很短，理想情况下只能执行一项任务。
您有足够的信息来调用方法而无需查看它们的主体。
单元测试很容易编写。

错误标志


由2-3个未分解为多个子任务的方法组成的长方法其他方法。
方法通过接口以外的其他方式共享数据。
如果更改一种方法（而不是接口）的实现，则需要更改其他方法的实现。
很多评论，尤其是冗长的评论。
您的代码永远无法在应用程序中运行，以提供“未来的灵活性”
大型try / catch块
您很难找到好的方法名称，或者它们包含“ “或”和“与”（例如GetInvoiceOrCustomer）
相同或几乎相同的代码块。

这里有较长的代码气味列表，这也将有所帮助。

#5 楼

就我个人而言，我认为这是我忘记代码的时候。换句话说：


错误很少发生
当错误发生时，其他人会解决它们而不会问我任何事情
更重要的是，没有人问过我什么关于我的代码
人们在阅读时没有很高的WTF / min
系统中的许多新类开始使用我的类（如史蒂夫·麦康奈尔所说的高扇入率）
很容易地在需要时修改和/或重构代码，而无需骂我（即使是我-骂我自己！）
当我猜到适量的代码时，我也喜欢它似乎适合团队中每个人的抽象

打开一年前编写的文件并看到类中所有不错的添加内容时，感觉很不错，但是修改很少，并且-很高的粉丝度！ :)

当然，这些使我感到自己正在编写良好的代码，但实际上，这真的很难知道。我的猜测是，如果人们开始取笑您的代码多于取笑您，那么该担心了。

#6 楼

我有三个黄金法则：


如果我不得不复制/粘贴代码块，那我做错了什么
如果我不能把整个代码都拿走头我做错了什么
如果有人跳入并迷失了我的代码，我做错了什么

那些规则指导我进行了一些实际的体系结构改进，最终导致小型，干净且易于维护的类/方法。

#7 楼

这是一个很好的问题，我为您甚至提出的问题而称赞。

首先，让您的头脑不时地振作起来是很好的。让您保持谦虚，让您意识到自己不了解所有事情，没有比这更好的人了，并为您提供了更好的奋斗目标。

现在，您怎么知道什么时候编写好代码？



当您的每个类都具有一个单独的，非常明确定义的目的，并与其他具有其他明确定义的目的的类分开时。
当您的方法比较短时-理想情况下少于50行，当然少于100行-其名称清楚地定义了它们的确切功能。方法不应该执行任何操作，而是其名称所隐含的含义。如果您要遍历100行或跳到很远的地方，则可以将某些内容引入其自身的功能中。
当您的代码提供一种做某事的方式时-当它不提供zig或zag选项时，而是为每个可能的操作过程提供一条线性路径，用户可以将其向下发送。
完成所有步骤后，您可以合理地减少类之间的耦合；因此，如果A类依赖于B类，并且删除了B类并将其放置在C类中，则几乎不必对A类进行任何更改。A类应该尽可能地避免对A类中发生的事情进行盲目操作
当代码中的任何人都可以读取并立即理解您的类，方法和变量名时，当'packetSize'读得更多时，就不需要'pktSize'。

正如其他人所说，从本质上讲，如果您正在进行面向对象的编程，并且当需要更改某些内容时，您会发现它像试图解开并倒回毛线球一样，代码并没有很好地遵循面向对象的原理。

如果您有兴趣进一步研究此书，我强烈推荐这本书“ Clean Code”。这对于新手和专家都是不错的阅读。

#8 楼

我的主要观点是：



可读性（对于您和其他研究您代码的人）

Maintainability（易于修改）

简单（不需要时不复杂）

效率（当然，您的代码应快速执行）

清晰（如果您的代码是不言自明的，那么大多数时候就不需要注释，命名您的方法/属性等。明智地，将冗长的代码分解，永远不要复制和粘贴代码块）

我不会将“设计”放在此列表中，因为我相信只要您的项目中保持一致，就可以编写出良好的代码而无需遵守设计模式。

关于此主题的MSDN优秀文章：什么使好的代码良好？

#9 楼

环顾四周，用自己喜欢的语言找到一个好的开源项目，然后看看它们的作用。例如，sendmail是寻找是否编写意大利面条式代码的地方。确实不是sendmail的错；它只有20年的历史，所以里面很多东西。因此，如果您的代码看起来像sendmail代码，那么您可能走错了路。

我最近还没有看过Postfix，它的设计可能很好。因此，如果您的内容看起来更像后缀，那么您的方向就正确了。

当我还是个孩子的时候开始编程时，没有互联网，您无法与之相比。但是现在有了成千上万的可供查看的代码行，您可以对是否做得正确有所了解。

仅因为Linux内核是Linux内核就可以了。并不意味着它写得很好。请记住这一点。

#10 楼

自从过去五个月从编程的大学领域转向行业以来，这一直是我的经验：易于使用非常重要，以至于我们只为设计用户界面而付钱。编码人员通常会迷上UI设计。
您发现，使其正常工作还不够
在现实世界中，优化变得越来越重要。
有上千种解决问题的方法。但是，通常情况下，这种方法并不能解决一些不太知名的因素，这些因素可能会对您的方法的性能产生不利影响，例如数据库身份验证，事务，文件I / O，反射，仅举几例。
可维护性是编码的一个非常重要的方面。仅仅因为您的代码经过超级优化和超级密集……并不意味着它很性感。有时它被简单地标记为“英雄编码”。
学习的是设计技能，而不是固有的。我敢肯定有一些脑力激荡的孩子，但是总的来说，针对现实世界问题的可靠设计需要时间，调查，而且最重要的是，要向上司传授知识= P
文档化不是便利，而是必要。
单元测试也是如此（当然，每个公司的情况都不尽相同）

我建议您抓住机会尝试一下开源项目。如果您与其他程序员一起工作，您将有机会了解您真正了解多少。开源项目可能是根据您的背景进行查找的最佳方法。

#11 楼

当您可以像散文一样阅读它时。

#12 楼

从代码和设计的角度来看，我喜欢其他人已经谈到的可维护性。

此外，我还关注稳定性。查看生产支持统计信息。如果您获得了看似基本功能的支持支持实例，但却发现许多人不了解如何使用该软件或发现该软件无法满足他们的需求，则说明存在问题。

当然，有些用户确实一无所知，但是如果随着时间的流逝，您仍然收到有关损坏，混乱或重大功能更改请求的报告，则表明以下一项或多项操作：适用：


要求已被破坏
代码已被破坏
应用程序不直观
开发人员不了解用户的需求
有人要求交货日期超过质量
有人没有很好地测试或不知道要测试什么

#13 楼

阅读良好的代码并弄清楚为什么如此。阅读错误的代码，找出原因。阅读平庸的代码，找出哪些部分是好的，哪些是坏的，哪些是好的。阅读您自己的代码并执行相同的操作。挑选几本（备受好评的）教科书，专门用于查看示例并理解为什么以这种方式编写示例。通常，请阅读代码，直到您可以分辨出好与坏之间的区别，并且可以自己编写“ Wtf？”。测试。

您通常无法识别出良好的代码，然后才能知道自己是否在编写良好的代码。仅仅因为您头顶上的东西并不代表它写得好...

（“阅读其他人的代码”在此线程上弹出了几个注释，但我认为应该这样做自己的帖子）

#14 楼

让别人接管您的工作一天，并检查他或她一天结束后的压力如何；-)

我不擅长记录和清理东西-所以我如何检查。

#15 楼

话虽这么说，我感觉我
从来不知道我的程序是否很好。
当然可以，但是
代码是干净，紧凑，写得很好的东西吗？
还是另一个编码器会看它并
把我打在脑海？


您是否考虑过问另一个编码员，他们对您的代码有何看法？

有些地方使用“同行评审”，即代码必须被另一个编码器接受，然后才能被代码存储库接受。

#16 楼

恕我直言，本质上没有“好的代码”，但是有“好的软件”。

当我们在做某事时，我们的工作受到很多约束，很多时候这会使我们产生不符合其他程序员的“好代码”标准的代码。

有人可能会说“好的代码”是易于维护的代码。对我来说，这种说法的反驳是，多么容易？我们是否需要花200％的精力来编写代码，以使其易于维护以实现“良好代码”标准，即使我们知道我们不需要维护那么多代码也是如此？很抱歉，我不这么认为。

实际上，我是在团队中真正推广“良好代码”的人，没人真正关心它。每次查看他们的代码时，我从未发现他们编写过任何完美的代码。但是，我必须接受他们确实完成了工作，并且能够充分满足我们公司的需求。当然，该应用有时有时会出错，但是我们只是及时完成了，这使我们的客户和用户感到满意，并使我们的公司遥遥领先于竞争对手。

所以，我要说的是：好的代码”就是产生所需内容的代码。您只需要考虑自己的真正需求，然后使用它来评估您的代码。

#17 楼

好的代码对人而言是主观的。一个专业的编码人员，读过很多书，参加过各种研讨会，并且使用了不同的编码技术，可能会把您的代码撕成碎片……但是，我发现代码确实表明了编码人员的经验水平。对我来说，它读起来就像一本历史书或一本自传。这是编码人员当时所知道的，或者他/她仅限于使用什么工具。

问问自己... Microsoft为什么要使用3个版本的软件才能正确处理问题？因为他们一直在纠正他们在先前版本中犯的错误。我知道我的代码在修订后总是越来越好。当然这里会有人说，我第一次写代码完美。如果您相信，那么我有一些沼泽地可以卖给您...

当您了解概念时，事情就会变得容易起来。对我来说，开始学习新东西是“我能使它工作吗？”，然后下一步是“我想知道我是否可以通过这种方式...”，然后通常在钉牢后我会问“如何使它变得更快” ...

如果您想成为一名程序员，那么您就必须深入研究它，然后再去做。这需要大量的工作，老实说，这就像一件无法完成的艺术品。但是，如果您只是想成为一个休闲爱好者，那么如果它起作用了，那就不用担心了。您必须适应周围的环境。如果您没有办法进行代码审查，那么无知是极乐=）

但是无论如何...每个人都会有自己的看法。当然，有正确的做事方式和错误的方式...但是大多数我发现，有比错误的方式做事更好的方法...

#18 楼

对于特定的代码段：

，如果它可行且可维护（请遵循您的良好做法），那么它就是好的代码。

对于您作为开发人员而言，随着时间的推移：

好是相对和动态的术语，涉及语言领域，问题领域，当前趋势，最重要的是您的经验。对于这个连续体的“良好”酸测试可能只是回顾您以前的工作，如果您说“我真的真的那样解决过吗？”那么您仍然有可能成长，并有可能继续编写良好的代码。

如果您回顾并看到完美的代码，那么您也可以-完美，并且有停滞的风险，并且您可能很快就会停止编写良好的代码。

#19 楼

释放您的代码，让一些人弄乱它，以确保它能够执行应有的功能。或者，如果您愿意，请设计规格并确保其符合所有这些规格。如果您通过了这两项测试中的一项或两项，则您的代码“立即适用”。对于大多数人来说，您的代码将永远都很棒，因为您会在一年后回来并说：“为什么这样做会更好，为什么我要这样做呢？”

更多的经验，您可以获得更好的代码。但是，如果您不断练习相同的习惯，那么您将不断陷入同样的​​陷阱。这只是古老的格言“实践使人永久”。如果您继续以正确的方式做事（例如测试您的代码以始终确保其能够按预期执行工作），那么您会变得更好。如果您继续以错误的方式做事（例如，从未在某些情况下测试代码，或者无法识别可能在哪里发生错误），您只会对代码感到固执。

#20 楼

拥有经验丰富的人员来查看您的代码是无与伦比的，但是有一些资源可以帮助您自己评估和改进代码。看看Martin Fowler的Refactoring（或网站）。如果您使用C ++编写，则Sutter和Alexandrescu的C ++编码标准很好。其中有很多建议与语言无关，但是其他建议也可以为其他语言推荐类似的书籍。测试驱动的开发对单独的开发人员非常有用，因为它可以在您进行过程中提供某种质量检查，并且您知道当测试变得难以编写时，这意味着您的代码可能可以使用重组。

其他一些迹象更注重过程。它们通常会导致更好的代码，但不是直接的。其中包括诸如使用源代码控制，自动构建过程，不直接在实时服务器上进行开发，使用错误跟踪软件等。

#21 楼

您可以使用代码分析工具，例如FindBugs，PMD。这将提供有关代码质量的一些信息。

#22 楼

为了更好地编写代码，我旨在确保该程序具有较高的功能和速度。确保所有内容都放置在适当的位置，以使文件，数据，功能和抽象非常明显。

之后，我进行了测试：在计算机中找到一个相当精通的人一般来说，尝试解释一些主要的代码模式。如果他们能读某种书，哇。干得好。

大多数情况下只是KISS并尝试创新，而不会崩溃。我还会对返回到代码并有一段不错的时间来改进和维护它做更多说明，但这已经很好地覆盖了。

#23 楼

永远不会。

“好的代码”只是尚无改进方法的代码。
正如Jeff Atwood所说：


是世界上少数能够产生精妙，完美代码的程序员。我们剩下的
所能做的就是让我们的
软件随着时间的流逝而变得不那么肮脏-持续改进的过程



这样，您就不必达到完美，因为有时，“充分的设计意味着糟糕的设计”。

#24 楼

我用5点来知道代码是否好：


过程，方法和类名都非常有用，但可以告诉我它们的作用。
任何包含的原因都会导致无法运行
一个月后查看代码，我可以按照流程
代码进行编译并干净地运行。
程序执行预期的操作，并且仅执行预期的操作。

对我来说，GetCustIDFromDB（var＆ast; DB，char＆ast; customer）比getcid（var＆ast; DB，char＆ast; c）更好，因为它可以告诉我我在看什么。但是* DBLookupCIDByName（var＆ast; DB，char＆ast; customer）也可以。

我经常测试看看我是否实际上仍然使用我所有的#includes ...如果可以删除它，很好。有时，可以检查您包含的标头，并通过#include来查看标头包含的内容中实际上是否需要的函数……但是我很少这样做，而且还节省了一些空间， “这可能会使添加新功能的过程变得更加困难。

#25 楼

这很难说。总是存在一个问题，那就是需要更长的时间来正确地做它，或者花费更少的时间来更快地完成它，以便您可以从事其他工作。

http://xkcd.com/844/

我回头看了看几年前编写的代码，我认为它看起来很糟糕。我们在这一领域不断学习，正确编写代码的最佳方法是查看他人的示例并从中学习。一旦您学到新东西，就可以与他人分享，以便我们所有人都可以从中受益。