您实际上写的是“干净的代码”吗？[关闭]

我已经看到一些程序员一遍又一遍地调整他们的代码，不仅使它“运行良好”，而且使它“看上去良好”。

IMO，“干净代码”实际上是对您代码的优雅，完美理解和可维护性的一种称赞。而且，当您不得不在美观的代码和压力很大的代码之间进行选择时，就会出现区别。

那么，你们当中有多少人实际编写了“干净的代码”？这是一个好习惯吗？这样做的其他好处或缺点是什么？

我会辩称，我们中许多人没有编写干净的代码。通常，这不是我们的工作。作为软件开发人员，我们的工作是按时交付有效的产品。

我想起了Joel Spolsky的博客文章：Duct Tape Programmer。

他引用了编码员的工作：

最终，运送f ***** g东西！重写代码并使其更加整洁是一件很不错的事，到第三次，它实际上将变得很漂亮。但这不是重点–您不是在这里编写代码；您在这里运送产品。-杰米·扎温斯基

我也想起了罗伯特·马丁（Robert Martin）的博客回复：

所以。放聪明点。要干净 很简单 船！准备好一小卷胶带，不要害怕使用它。-鲍勃叔叔

如果开发人员编写的代码恰好干净而且可以正常工作（可以交付），那么对所有人都有利。但是，如果开发人员不停地尝试制作清晰易读的代码，却以无法及时交付为代价，那就不好了。使它工作，使用胶带将其运输。您可以稍后对其进行重构，使其变得超级华丽和高效。

是的，编写干净的代码是个好习惯，但是绝不以牺牲交付能力为代价。准时交付带有导管的产品的好处远远超过了从未完成和交付的干净代码的好处。

我遇到的很多代码都不干净。有些非常丑陋。但是它们都已发布并用于生产。有人可能会说编写混乱的代码是不专业的。我不同意。专业的工作是交付有效的代码，无论它是干净的还是杂乱的。给定交付前分配的时间，开发人员必须尽其所能。然后，回去清理-专业。希望提供的代码不是纯胶带，而且“足够干净”。

您必须确保您的代码具有很好的可读性，整洁性和可维护性。那是所有程序员必须做的。

但是，您所谈论的over styling（就像那个术语比“ 女孩代码”更好）只不过是作者的自我。

我曾经看到许多开发人员为自己的创造感到骄傲（就像在洗手间一样；），他们花了数小时来清理和完善代码。其中一些非常细致，以确保确保成员之间的正确空白。

太多了。

我发现这种行为适得其反。在专业背景下，您必须是专业人士。通过编写干净，可读性强和可维护的代码并与快乐的用户或同事交谈，您可以获得满意的结果。

我不同意这个问题的答案。

您的责任显然是发货，但是通常您也有责任发货自己和未来的开发人员可以以成本有效的方式维护的东西。

我曾经在现场担任过糟糕的维护程序员或顾问，不得不理解和调试一些庞大的未记录系统，并且我可以告诉您，糟糕的设计和混乱的代码可能导致数小时甚至数天的浪费。我可以想到许多情况，最初的开发人员多花费N个小时可以节省5N的时间。

我知道这方面有一个统计数据，但是根据我在多个项目中的经验，在扩展和维护期间，每行编写的代码被读取5至20次。

因此，我想说的是将代码清理到其寿命的一英寸以内。这需要时间，但是可能会在项目的整个生命周期内节省净成本。

如果我们知道在引擎盖下进行故障排除，维护或修理非常麻烦并且难以进行，并且需要花费更多的资源来运行，那么我们中的任何人都会买车吗？

为什么一件软件会有什么不同？

仅仅因为最终用户看不到内幕，并不意味着他们永远不会知道。迟早会出现。

回答问题“您实际上编写'干净的代码'吗？” - 哦耶。！

如果用“干净的代码”表示您是要竭尽全力确保代码尽可能清晰？

哎呀。

代码越干净，代码越清晰，维护起来就越容易，从长远来看，可以节省您的时间。不要将干净的代码视为虚荣。将其视为节省未来精力和时间的一项投资。

老实说，这取决于。我喜欢每个人都大声疾呼有关“干净的文档之外的任何东西都是纯粹的琐事！”的话题，但是我在一个部署周期短且零监督的企业中工作：我会尽我所能，但是我写很多代码很难编写其他人都声称自己编写的干净，完美的代码。

我尝试编写可由具有大致能力的人轻松维护的代码。我评论棘手的部分，命名程序，变量和类的友好名称，部署并继续。我没有时间做其他事情。

有时我对此感到内，但不是很内.。您应该看到我每天都会处理的一些恐怖事件。数十种模糊语言的自定义代码，零文档。我的一位同事专门在Visual Basic 6.0中进行开发，并在各处部署了以秘密方式命名的二进制文件。我取代的女人只在RPG中编程。

我很难相信，就像我作为程序员的那几年所看到的那样可怕的废话，就是每个人只会生成干净的代码。

我认为我不喜欢“女孩代码”一词，但干净的代码=可维护的代码。什么都不是专业的。

作为一般规则，我考虑下一位不得不看我一团糟的开发人员。

很多时候是我...几个月后...当我不记得它是如何工作的...而我进行更改的时间更少了。

我尝试用鲍勃·马丁的感觉（例如OO设计）编写“干净的代码”。有伟大的书面干净的代码值。它更易于维护。

然后，我让ReSharper为我创建“漂亮的代码”（例如对齐，换行等）。编写漂亮的代码具有很好的价值。但是回报却在减少。由于易于阅读，有些修饰使其更易于维护。

如果您认为整齐地排列巨大的代码块以使其具有可读性是必要的，那么问题是您的freakin巨大的代码块！这个太大了。我看到许多例子，说明人们非常努力地美化一些设计很差的代码。

如果我没有ReSharper，我仍然会拥有干净的代码，但它不会那么漂亮。

我认为我花在美化上面的时间不会超过5％。这意味着我的编辑器越强大，越熟练，就可以做得越漂亮。

似乎没有人提出您公司的最大利益所在？

通常，程序员（如果不是总是这样）只是员工，尽管管理决策可能使我们感到沮丧，但我们常常没有他们所做的所有数据。

例如，假设该公司签订了一项条款，规定如果软件未及时准备就绪，您将不会获得付款（这只是发生在我们身上，尽管我认为我们毕竟已经付款了）。是的，干净的代码很重要，但更重要的是要在付款日之前使代码正常工作！

另一个例子-公司财务状况不佳，需要筹集一些资金。猜猜谁在乎质量？您可以稍后对其进行修复，如果需要的话，就可以发货！

一个参数可能是“为什么我应该卖光并编写糟糕的代码？”。好吧，为什么您的公司每月都要给您一张不错的支票？选择，我的朋友。如果您追求理想主义，请尝试免费软件基金会（Free Software Foundation）；我听说他们在做一些很酷的事情（我的意思是，我尊重FSF和OSS）。

另一方面，如果您在一个预期使用量会爆炸性增长的项目上工作（尽管这样的预测几乎永远都不是准确的），那么您最好为所需的最佳代码质量打下坚实的基础，因为几乎可以肯定，维护会是项目的更大成本。

程序员喜欢“干净”的代码，无论这意味着什么。我们甚至无法就干净的东西达成共识，但是我们喜欢它。但是，有时它与可用性和正确性无关紧要。这些看起来似乎是同义词，但并非如此-如果您在4个小时内就看到一个真正的Perl黑客编写的代码，意图被使用两次并扔掉，那么您会意识到它不是干净的，但是可以。

所以有时候，除了自我，我们应该让它工作。请注意，我不建议编写不良代码作为习惯。我只是指出这可能是必要的。完善需要您的公司可能没有的时间。因此，如果您的雇主不介意制作软件，但是如果您需要的话，只需编写工作代码，不要介意“清洁”。这不是“一刀切”的答案-您应该优先考虑。

我不确定“看起来不错”和“优雅，完全可以理解和可维护”是否等效。

我尝试编写代码，即“优雅，完全可以理解和可维护”。我确实重构了自己的代码以更好地符合这些条件。

除了造成的时间成本外，我看不到任何弊端。

为了使代码“看起来不错”，有大量的自动化工具，可以根据需要适当缩进和间隔所有内容。

太多的事情永远都没有好处。

但是，“不干净”的代码要记住的重要一点是，它很容易导致“ 破损的窗口 ”。如果代码的格式很差，我认为许多新手可能会不太愿意做好维护和升级工作，从而导致螺旋式下降，最终可能会影响软件的工作状态。

因此，在代码中保持一定程度的整洁不仅对您的同伴开发者有所帮助。不要在上面花费太多时间（已经提到了5％）。了解如何使用自己的工具来自动执行手动任务（在这种情况下为代码格式）。对您所做的事情负责，并始终做对您的公司/客户/用户最有利的事情。

这是鲍勃·马丁（Bob Martin）的“清洁代码”的一句话：

为了把这一点讲清楚，如果您是医生并且有一个病人因为您花费太多时间而要求您停止所有愚蠢的洗手以准备手术，该怎么办？显然，病人是老板。但是医生绝对应该拒绝遵守。为什么？因为医生比病人更了解疾病和感染的风险。医生遵从患者的要求是不专业的（不要介意犯罪）。

因此，程序员屈从于不了解搞乱风险的经理的意愿也是不专业的。

我认为“干净的代码”应该比您以前在物理/工程/数学考试中写的代码更干净或更干净。如果太乱了，则平地机将不会理解您的工作，即使正确，也可能会将其标记为错误。

我喜欢代码易于阅读，但是最重要的是一致性。对我来说，这意味着与命名约定和函数之间的间距，if语句的同一行或下一行的括号等保持一致。

当然，有时候有人用一致的代码样式编写某些东西，但仍然让我发疯。特别是不会“呼吸”的代码。例如：

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

好吧……使用Objective-C方法看起来更糟，而且嵌套了很多if语句，并且行长于80个字符。但这仍然让我很烦:)

我确实竭尽全力清理代码。我认为这可以极大地帮助Bug脱颖而出。

我不同意“立即运送他妈的东西”的概念，因为干净的代码是对未来的投资。另外，太多的软件附带了太多的错误。我认为解决一个错误比实现一项新功能要好。

另外，如果您看一下程序员的生产率估算值，我认为我的得分不会很差。编写干净的代码是一种习惯，作为程序员的经验越多，使用它的效率就越高。如果一个人从不尝试，显然，它将永远不会获得经验。

要考虑的另一点是，大多数开发人员将时间用于阅读代码，因此可读代码大大减少了阅读时间。例如，了解未公开的算法可能会很昂贵，并会引发新的错误。

我肯定会想念的一件事，就是希望有一天能自动适应我的风格，这确实可以为我节省一些时间，特别是在阅读其他人的代码时。

干净的编码确实有与完美主义的联系，这确实有可能永远不会实现，但是我认为这主要是在您入门时遇到的一个问题，因为您在以后进行投资以及在重用自己优雅的代码段时结合您的经验，随着年龄的增长，与杂乱的编码器相比，您将变得非常有生产力，并且不会被错误困扰。

这是一段代码，展示了我的编码风格。

只是避免使用“虚荣代码”。那里有很多开发人员纯粹是出于虚荣（或由于OCD而已）来做事情，而没有其他事情。我的内裤真的和那些人在一起。

我编写的代码试图以最有效和理论上“优雅”的方式解决给定的问题。从这个意义上讲，它是干净的。如果完成后碰巧是“漂亮”，那就这样吧。

我从有限的经验中发现，当人们抱怨“干净代码”时，丑陋通常是可怕的解决方案而不是编码约定的结果。

我会说我努力写出更简洁的代码，但是由于时间限制或我正在做一些困难的事情，这种情况可能会改变。当专注于使其工作时，它往往变得混乱。然后我回去整理一下。如果返回到代码并且不得不花太多时间刷新内存，那么您的注释不够。

干净的代码很好，但是像其他所有代码一样，它只需要足够干净即可。缩进5行代码4空格和1行5空格不会增加阅读难度。

我认为这取决于您在做什么。如果我正在编写概念验证应用程序，那么我基本上是在牛仔编码我的屁股，而不回头。如果我正在开发实际上将要使用一段时间的应用程序，那么请确保我编写的代码足够好，并且一个月后就可以理解。

我认为样式化代码有点麻烦。如上文所述，您的工作是制造一种产品，而不是格式化代码，但我要说的是至少应该坚持一种定义的注释和编码风格。我不希望看到一半的骆驼变量和另一半的匈牙利语。

但是，这还取决于您所说的“干净代码”。

我承认这样做；而且每次看到它的好处都不会被烦恼。我想它也更容易阅读，因此错误变得更加明显。但真正的原因是我受不了难看的代码。

重构代码以使其美观大方，使其更易于阅读和维护。甚至很小的事情，例如对齐变量分配：

int foo    = 1;
int bar    = 2;
int foobar = 3;

比起阅读更容易

int foo = 1;
int bar = 2;
int foobar = 3;

这意味着以后进行调试时更容易浏览。

另外，在PHP中，您可以使用任意数量的随机代码块。我用这些对逻辑任务进行分组：

// do x
{
    // ...
}

// do y
{
    // ...
}

这为相关代码添加了清晰的定义。

编辑：作为一项额外的奖励，if (false)如果您想暂时跳过这些逻辑代码块之一，则可以轻松地在其中加上一个逻辑代码块。

我只是按照公司标准编写代码。如果我希望它“漂亮”，则可以通过代码美化程序运行它。