我正在编写一个 Javascript 代码，我需要在其中显示和隐藏 Web 的某些部分。我最终得到了这样的功能：

我的问题与代码质量和重构有关。什么时候最好有像这样的简单函数或直接调用 Javascript/jQuery 函数？我想最后一种方法有更好的性能，但在这种情况下性能不是问题，因为它是一个非常简单的站点。

我认为拥有这样的函数没问题，毕竟 hideBreakPanel 以后可能涉及的不仅仅是将类应用于元素。我要指出的唯一一件事是尽量减少这些函数中重复代码的数量。不必担心会增加函数调用开销，除非您在性能关键场景中执行此操作，否则运行时解释器不会在意。

一种安排功能以避免重复的方法：

如果你绝对必须有一个速记，你可以这样做：

甚至

这样您将常用功能封装在一个函数中，您不必更新所有隐藏函数来修改隐藏的完成方式。

My question is related with code quality and refactoring. When is
better to have simple functions like these or invoke a
Javascript/jQuery function directly? I suppose that the last approach
have a better performance, but in this case performance is not a
problem as it is a really simple site.

从一般的angular来看，如果你有很多单行函数和多行代码塞进一个类似的东西，如果目标仅仅是语法糖和非常个人对清晰度的定义(这可能是非常短暂的，并且会像时尚趋势一样发生变化)。

这是因为赋予代码寿命的质量通常首先是熟悉度，其次是集中化(需要跳过的代码分支更少)。能够识别而不是绝对厌恶你多年后编写的代码(例如，不觉得它奇怪/陌生)通常有利于那些减少系统中概念数量的品质，并流向非常地道地使用语言和库。除了正式的 SE 指标之外，这里还有人类指标，例如保持相同代码的动力。

但这是一个平衡的行为。如果寻求这些更短更甜美的函数调用的动机更多地与语法之外的概念有关，例如拥有一个修改、扩展和检测行为的中心位置，以提高其他容易出错的代码的安全性等，那么即使是一堆单行函数的功能在未来可能会开始变得很有帮助。在这种情况下，保持熟悉的关键是确保您(和您的团队，如果适用)对此类功能有足够的重用性，并将其纳入日常实践和标准。

这里的惯用代码往往是相当安全的，因为我们往往会被它的例子所淹没，保持熟悉。每当您开始深入建立专有接口时，我们就有可能失去这种质量。然而，专有接口肯定是需要的，所以关键是让它们发挥作用。

另一种深奥的观点是，相互依赖的功能往往会一起老化。仅对语言提供的非常简单类型进行操作的图像处理功能往往会老化。例如，我们可以找到可以追溯到 80 年代的此类 C 函数，这些函数在今天仍然相关且易于应用。这样的代码很熟悉。如果它依赖于非常奇特的像素和颜色库以及超出规范的数学例程，那么它往往会老化得更快(失去熟悉度/适用性)，因为该图像处理例程现在随着它所依赖的一切而老化。再说一遍，总是着眼于走钢丝的平衡和权衡，有时避免冒险超出规范的诱惑是有用的，并避免将您的代码耦合到过多的奇异接口(尤其是那些服务不多的接口)比糖)。有时，有利于减少概念数量并更直接地使用系统中已有内容的稍微冗长的代码形式可能更可取。

然而，通常情况下，这取决于。但在做出所有决定时，这些可能是一些不常提及的品质。

如果 resetInputValues() 方法返回 undefined (意味着什么都不返回，例如)或任何虚假值，你可以将它重构为：

使用例如 togglePanel('break'); 代表 showBreakPanel() 和 togglePanel('break', true) 代表 hideBreakPanel()。