CODEWITHSUNDEEP
javascriptjquerycoding-stylerefactoring
David Moreno García
David Moreno García

Reputation: 4523

Use single line functions or repeat code

I was writing a Javascript code in which I needed to show and hide some sections of a web. I ended up with functions like these:

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');
}

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.

Upvotes: 3

Views: 497

Answers (3)

user4842163
user4842163

Reputation:

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.

Just from a general standpoint, you can get into a bit of trouble later if you have a lot of one-liner functions and multiple lines of code crammed into one and things like that if the goal is merely syntactical sugar and a very personal definition of clarity (this can be quite transient and change like fashion trends).

It's because the quality that gives code longevity is often, above all, familiarity and, to a lesser extent, centralization (less branches of code to jump through). Being able to recognize and not absolutely loathe code you wrote years later (not finding it bizarre/alien, e.g.) often favors those qualities that reduce the number of concepts in the system, and flow down towards very idiomatic use of languages and libraries. There are human metrics here beyond formal SE metrics like just being motivated to keep maintaining the same code.

But it's a balancing act. If the motivation to seek these shorter and sweeter function calls has more to do with concepts beyond syntax like having a central place to modify and extend and instrument the behavior, to improve safety in otherwise error-prone code, etc., then even a bunch of one-liner functions could start to become of great aid in the future. The key in that case to keep the familiarity is to make sure you (and your team if applicable) have plenty of reuse for such functions, and incorporate it into the daily practices and standards.

Idiomatic code tends to be quite safe here because we tend to be saturated by examples of it, keeping it familiar. Any time you start going deep on the end of establishing proprietary interfaces, we risk losing that quality. Yet proprietary interfaces are definitely needed, so the key is to make them count.

Another kind of esoteric view is that functions that depend on each other tend to age together. An image processing function that just operates on very simple types provided by a language tends to age well. We can find, for example, C functions of this sort that are still relevant and easily-applicable today that date back all the way to the 80s. Such code stays familiar. If it depends on a very exotic pixel and color library and math routines outside of the norm, then it tends to age a lot more quickly (loses the familiarity/applicability), because that image processing routine now ages with everything it depends on. So again, always with an eye towards tightrope-balancing and trade-offs, it can sometimes be useful to avoid the temptation to venture too far outside the norms, and avoid coupling your code to too many exotic interfaces (especially ones that serve little more than sugar). Sometimes the slightly-more verbose form of code that favors reducing the number of concepts and more directly uses what is already available in the system can be preferable.

Yet, as is often the case, it depends. But these might be some less frequently-mentioned qualities to keep in mind when making all of your decisions.

Upvotes: 2

A. Wolff
A. Wolff

Reputation: 74420

If resetInputValues() method returns undefined (meaning returns nothing e.g) or any falsy value, you could refactorize it to:

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

Use e.g togglePanel('break'); for showBreakPanel() and togglePanel('break', true) for hideBreakPanel().

Upvotes: 1

Andrei Nemes
Andrei Nemes

Reputation: 3122

I think you're fine with having functions like these, after all hideBreakPanel might later involve something more than applying a class to an element. The only thing I'd point out is to try to minimize the amount of repeated code in those functions. Don't worry about the fact that you're adding a function call overhead, unless you're doing this in a performance-critical scenario, the runtime interpreter couldn't care less.

One way you could arrange the functions to avoid repeating yourself:

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

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

If you absolutely must have a shorthand, you can then do:

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

Or even

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

This way you encapsulate common functionality in a function, and you won't have to update all your hide functions to ammend the way hiding is done.

Upvotes: 4

Related Questions