Question

我正处于信息技术学士学位课程的第二年。去年，在我的一门课程中，他们教我编写干净的代码，以便其他程序员更轻松地处理您的代码。我从复数形式的视频（“干净的代码”）（我的学校使用的付费学习网站）上学到了很多有关编写干净的代码的知识。那里有一个关于将条件分配给布尔变量并使用它们来提高可读性的示例。今天在我的课程中，我的老师告诉我，这是非常糟糕的代码，因为由于执行的测试增加，它会降低性能（在较大的程序中）。我现在想知道是否应该继续使用布尔变量以提高可读性，还是不使用它们来提高性能。我将在一个示例中进行说明（我在此示例中使用的是python代码）：

示例布尔变量

比方说，我们需要检查某人是否合法饮酒，我们可以确定该人的年龄，并且知道合法饮酒年龄是21岁。

    is_old_enough = persons_age >= legal_drinking_age
    if is_old_enough:
        do something

我的老师今天告诉我，这将对性能造成很大影响，因为先进行了2次测试，然后才进行测试，然后再进行另一个测试，确定该人是否年龄足够大。我的老师告诉我，我应该把条件放在if中，但是在视频中，他们说代码应该像自然语言一样阅读，以使其他程序员清楚明白。我现在想知道哪种编码方法更好。

以下情况的示例条件：

if persons_age >= legal_drinking_age:
    do something

在此示例中，仅测试了1个测试，测试人员年龄是否大于等于Legal_drinking_age。根据我的老师，这是更好的代码。

提前谢谢！

您忠实地

乔纳斯

Answer 1

我现在想知道哪种编码方法更好。

真正的安全答案是：视情况而定。

我不喜欢使用这个答案，但是除非您有真实的疑问，否则您不会问。（：

恕我直言：

如果该代码将用于长期使用，并且维护性很重要，那么首选清晰易懂的代码。

如果程序的速度性能至关重要，那么任何使用较少资源的代码操作（较小的dataSize / dataType / less循环即可实现同一功能/优化任务排序/每个时钟周期最大化cpu任务/减少数据重新加载周期）更好。（示例关键字：时空代码）

如果使内存使用最少的程序至关重要，那么使用较少存储和内存资源来完成其操作的代码操作（对于同一任务可能需要更多的CPU周期/循环）会更好。（例如：数据/ RAM有限的小型设备）

如果您正在参加比赛，则可以编写尽可能短的代码（即使以后可能需要稍长的CPU时间）。例如：Hackathon

如果您正在计划教一组学生/朋友一些东西。那么，首选可读代码+大量注释。

如果是我..我将坚持使用尽可能最接近汇编语言的任何东西（对位操作进行尽可能多的控制）进行后端开发。以及任何与数学类代码最接近的东西（更少的代码，最大的输出，实际上并不关心需要多少cpu /内存资源）用于前端开发。（：

所以..如果是您..从用户/外部/客户的角度来看，您可能有自己的要求/偏好..它只是一个工作/不工作的程序。是的，我们对好的程序的定义可能会与其他程序有所不同。但这不应该阻止我们在编码风格/方法上保持灵活性。

探索愉快。希望它对您有帮助。

Answer 2

性能

性能是此问题最不令人关注的问题之一，我说这是在非常关键的领域工作的，例如图像处理和光线跟踪，他相信有效的微优化（但是我的有效微优化思想会例如改善内存访问模式和内存布局以提高缓存效率，而不是因为担心编译器或解释器可能会分配额外的寄存器和/或利用额外的指令而消除临时变量。

之所以没那么有趣是因为，正如评论中指出的那样，任何体面的优化编译器都会在完成中间表示的优化并生成最终结果时将您编写的这两个代码视为等效。指令选择/寄存器分配以产生最终输出（机器代码）。而且，如果您没有使用像样的优化编译器，那么这种微观效率可能就是您要担心的两种方式中的最后一件事。

变量范围

除了性能之外，我唯一需要关注的约定是宽泛的应用，对于那些没有命名常量概念以将其与变量区分开的语言，

在这种情况下，引入到 meaty 函数的变量越多，随着范围相对较宽的变量数目的增加，它可能具有越多的智能开销，并且可以转化为实际负担在极端情况下进行维护和调试。如果您想象这样的情况：

some_variable = ...
...
some_other_variable = ...
...
yet_another_variable = ...
(300 lines more code to the function)

...在某些函数中，而您正在尝试对其进行调试，那么那些变量与该函数的巨大尺寸结合在一起，开始使试图找出问题所在的难度倍增。这是我调试各种类型的代码库时遇到的一个实际问题，这些代码库跨越了各种各样的人（包括不再在团队中的人）编写的数百万行代码，而在调试器中查看本地人观察窗口并看到两个在某些可怕的功能（或它调用的功能之一）中执行某些错误操作的页面中有价值的变量。

但这只是与可疑的编程实践（例如编写跨越数百或数千行代码的函数）相结合的问题。在那种情况下，通常只专注于使大小合理的函数执行一种清晰的逻辑运算并且不会产生多于一个的副作用（或者如果可以将该函数编程为纯函数，则没有一个理想的选择），通常会改善所有功能。如果您合理地设计函数，那么我将完全不用担心，并且一眼就能理解和理解最容易理解的东西，甚至是最可写和最“柔韧性”的东西（如果您期望的话，可以更轻松地更改函数）未来的需求。）

可变范围的实用视图

因此，我认为，只要了解缩小可变范围的必要性，就可以在一定程度上理解许多编程概念。人们说避免像瘟疫这样的全局变量。我们可以讨论共享状态如何干扰多线程以及如何使程序难以更改和调试的问题，但是您可以通过缩小变量范围来了解很多问题。如果您的代码库跨越十万行代码，那么全局变量将具有十万行代码的访问和修改范围，简而言之，十万种出错的方式。 / p>

与此同时，务实的观点认为编写仅跨越100行代码且无需将来扩展的单发程序是没有意义的，避免使用诸如瘟疫之类的全局变量，因为此处只会出现全局变量可以说有100行的作用域。同时，即使是在所有情况下都避免了瘟疫之类的人，仍然可能会编写一个带有成员变量的类（包括一些多余的“方便”变量），其实现跨越8000行代码，这时这些变量的作用域甚至比前一个示例中的全局变量，这种实现可能会促使某人设计较小的类和/或减少多余的成员变量的数量，以将其包括在该类的状态管理中（这也可以转化为简化的多线程和所有避免在某些非平凡的代码库中使用全局变量的类似好处。

最后，它也倾向于诱使您编写更小的函数，因为跨500行代码的某些函数顶部的变量也将具有相当大的范围。因此，无论如何，我这样做的唯一担心就是不要让这些临时局部变量的范围变得太宽。如果确实如此，那么通常的答案不一定是避免这些变量，而是缩小范围。

是否最好使用布尔变量替换if条件以提高可读性？

2 个答案: