Reassign parameter to local variable

Question

On Stack Overflow I frequently see questions with code in the following style:

function funcName(parameter) {
  let variable = parameter;
  // rest of function uses variable rather than parameter
}

Is this just some cargo-cult practice that some programming teachers pass on, or are there coding style guidelines that actually recommend it?

The only justification I can think of for this would be in languages that pass parameters by reference, if the function needs to reassign the variable without affecting the caller's variable. Is this a legacy of instructors who grew up learning Fortran, which passes all parameters by reference? Most other languages with by-reference parameters require them to be declared explictly, as in C++'s type &parameter declaration, and in these cases it's usually desirable to modify the caller's variable.

This style of coding for variables that are reassigned is discussed in Is there a reason to not modify values of parameters passed by value?. But I also see this in functions that only read the variable. For instance, this question has a function like this:

function say(messages = [{text: ' ', speed: 90, pause: false, colour: ['RED//BLUE']}]){        
  let alphabets = [];                                  
  let textLines = messages

  console.log(textLines.length)
  
  textLines.forEach((line, i) => {                       
    if (i < textLines.length - 1)  line.text += " ";   
    // more code
  });
});

It could just as easily be written with textLines as the parameter name.

Answer 1

It will happen if you want a different name for the parameter at the caller side and for the argument on the callee side. The developer making the call and the developer implementing the function can have different views of things.

Another situation are parameters being references and you don’t want to unintentionally modify the original, or read-only, or you want both a modified value and the original value.

So there are cases where it makes sense and cases where it doesn’t. If you see it, probably not worth changing.

Answer 2

Is this just some cargo-cult practice that some programming teachers pass on,

There are millions of teachers all over the world, so how shall we know?

or are there coding style guidelines that actually recommend it?

I have never seen one, but the situation is not different than the former: there are too many coding standards all over the world to answer this.

Hence I think it is impossible to answer this generically "for all questions on SO which use this style" in a sensible manner. One has to look at each individual case, review the code or ask the authors for their reasons. So please do yourself a favor and stop asking questions which wrongly assume the existence of some overgeneralizated answer.

In your specific example, however, I guess the two different names simply reflect the different points of view of the interface vs. implementation:

• on the caller's side, the function signature is just say(messages). The name messages just gives the caller a hint what the parameter should contain.

• from the implementors's point of view, those messages may be interpreted as text lines, so they will be given a different name. The primary context is here the internal agorithm. This is hidden from the caller, since it is an implementation detail.

So introducing a alias name can make sense in certain situations. However, for other situations there might be different reasons, or it is quite unneccessary - one has to look at each individual case.