在参数中声明一个数组是不好的做法？

Question

validationError([elem1,elem2],type,shiftNo);

or

var arr = [elem1,elem2];
validationError(arr,type,shiftNo);

What I mean to ask is approach 1 of calling the function considered bad ( also does it have any performance ramifications). and for that matter is it a bad approach to declare strings, object and functions inside arguments.

Answer 1

Performance is not an issue, not in a language like JS, Ruby or whatnot. So all we can do is think about code readability. And this case is not strongly related to JS, so will be my examples.

move = ["E2", "E4"];
if chessboard.valid(move, player) {
  ...
}

This clearly states: "if the move (E2 E4) is valid for this chessboard, then..." , you don't even need to look at the docs to know that. If we write that without assigning our array a name, the result looks a little cryptic (still easy to guess, but harder for such a tiny example):

if chessboard.valid(["E2", "E4"], player) {
  ...
}

What is this supposed to mean? What does valid stand for here? Maybe, it's asking whether these cells contain valid player's pieces? This is a sympthom of a design flaw, more precisely bad naming. It makes bold assumptions about how the chessboard code will be used. We can make it obvious that this array represents a move by renaming the chessboard 's method:

if chessboard.valid_move(["E2", "E4"], player) {
  ...
}

This is better, but you may not have an API that allows your code to stay so readable without some additional naming.

So, I suggest a rule of thumb:

1. If the array will be used more than once, name it.
2. If the meaning of the array is not obvious from where it goes (function name), name it.
3. Don't name it, unless points 1 or 2 apply.

Answer 2

It doesn't make any difference really. Either way, you create a Javascript Array , which basically is an Object and get a reference in return (which you pass to your method). If you don't need to access that array (or other data) later in your code, the second approach is completely fine.

Answer 3

It is subjective, but in my opinion it is better to use the second approach .

As @jAndy said there is no difference in the code execution neither the performance of your code, but it is easier to debug and easier to read and understand the second approach.

Answer 4

Are the contents of arr ever going to get used again? If so, then option 2 is definitely the way to go. If not... something as simple as this is probably just personal opinion.

Personally, I'd have to say that option 2 is better practice , even though sometimes I'm guilty of using option 1. Option 2 is easier to read, it's easier to follow and it's less likely someone will have to re-read it because they became temporarily confused or lost in flow of thought whilst reading through your code (especially newer programmers). For those reasons it's easier to maintain, you, and potentially future developers working with your code, will likely save time working with it.

The only negatives I can see would be generating an absolutely miniscule amount of overhead, and now you have 2 lines of code instead of 1. But I think that's irrelevant, the tiny potential benefits of option 2 outweigh the tiny negatives of option 1.