2015-11-19 24 views
3

我正在写一个Javascript代码,我需要显示和隐藏网页的某些部分。我结束了这样的功能:使用单行功能或重复代码

function hideBreakPanel() { 
    $('section#break-panel').addClass('hide'); 
} 

function hideTimerPanel() { 
    $('section#timer-panel').addClass('hide'); 
} 

function showBreakPanel() { 
    resetInputValues(); 
    $('section#break-panel').removeClass('hide'); 
} 

function showTimerPanel() { 
    resetInputValues(); 
    $('section#timer-panel').removeClass('hide'); 
} 

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

回答

4

我认为你有这样的功能很好,毕竟hideBreakPanel可能后来涉及的其他事情不仅仅是将一个类应用于元素。我唯一要指出的是尽量减少这些函数中重复代码的数量。不要担心添加一个函数调用开销的事实,除非您在性能关键的情况下这样做,运行时解释器并不在乎。

的一种方式,你可以安排的功能,以避免重复自己:

function hidePanel(name) { 
    $('section#' + name + '-panel').addClass('hide'); 
} 

function showPanel(name) { 
    resetInputValues(); 
    $('section#' + name + '-panel').removeClass('hide'); 
} 

如果你绝对必须有一个速记,然后你可以这样做:

function hideBreakPanel() { 
    hidePanel("break"); 
} 

甚至

var hideBreakPanel = hidePanel.bind(hidePanel, "break"); 

这种方式可以将通用功能封装在一个函数中,而且不必更新所有的隐藏函数来修正隐藏的方式。

+0

感谢您的回答。问题解决了;) –

+0

很高兴帮助你 - 对不起,我一直在更新答案,因为我想到了它 –

1

如果resetInputValues()方法返回undefined(意为不返回任何e.g)或任何falsy值,您可以将其refactorize到:

function togglePanel(type, toHide) { 
    $('section#' + type + '-panel').toggleClass('hide', toHide || resetInputValues()); 
} 

使用e.g togglePanel('break');showBreakPanel()togglePanel('break', true)hideBreakPanel()

2

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

只是从一般的角度来看,你可以进入一个有点麻烦以后,如果你有很多的单行函数和多行代码塞进一个之类的东西,如果目标仅仅是语法糖和一个非常个性化的清晰度定义(这可以是相当短暂的,像流行趋势一样变化)。

这是因为提供代码寿命的质量通常首先是熟悉度,并且在较小程度上集中化(较少跳转代码分支)。能够识别并且绝不讨厌你在几年以后写的代码(例如,不会发现它奇怪/陌生)通常倾向于那些减少系统中概念数量的特性,并且趋向于非常习惯性地使用语言和库。除了正式的SE度量标准之外,还有一些人类度量标准,比如只是被动机地维护相同的代码。

但这是一个平衡的行为。如果寻求这些更短和更甜的函数调用的动机更多地与语法之外的概念有关,比如有一个集中的位置来修改和扩展和检测行为,为了提高其他易出错代码的安全性等,那么甚至一堆的单线功能可能在未来开始成为巨大的援助。在这种情况下保持熟悉的关键是确保你(和你的团队,如果适用的话)有足够的重用这些功能,并将其纳入日常实践和标准。

这里的语言代码往往是相当安全的,因为我们倾向于通过它的例子来饱和,保持熟悉。无论何时您开始深入研究建立专有接口,我们都有可能失去这种质量。然而,专有接口肯定是需要的,所以关键是让它们数一数。

另一种深奥的观点是,相互依赖的功能往往会一起老化。一种图像处理功能只能在语言提供的非常简单的类型上运行,并且趋于老化。例如,我们可以找到这种类型的C函数,它们现在仍然相关且易于使用,可以追溯到80年代。这样的代码保持熟悉。如果它依赖于非常奇特的像素和颜色库以及规范之外的数学例程,那么它往往会更快地老化(失去熟悉性/适用性),因为图像处理例程现在随着它所依赖的所有东西而老化。所以,再次,总是着眼于走钢丝平衡和权衡,有时避免试图冒险超出规范的诱惑,并避免将代码耦合到太多奇特的接口(特别是那些只提供更多服务的接口比糖)。有时候,有利于减少概念数量并更直接地使用系统中已有的代码的略微冗长的代码形式可能更可取。

然而,情况往往如此,这取决于。但是,在做出所有决定时,这些可能是一些不太经常提及的品质要牢记在心。