0

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.

2 Answers 2

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.

1
  • 1
    But we're talking about exercise code, not code implementing an API with pre-ordained parameter names. The programmer gets to decide what the variables are named.
    – Barmar
    Oct 6, 2022 at 13:41
1

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.

7
  • I don't buy the messages vs. textlines "benefit". Especially since the code appears to have no EOL characters, hence no "lines".
    – user949300
    Oct 6, 2022 at 5:22
  • @user949300 Swift made this part of the language, so some people knowing lots about programming think it is an excellent idea.
    – gnasher729
    Oct 6, 2022 at 10:30
  • @user949300: maybe the internal variable name was not chosen well here, but that is pretty unimportant for my answer. The point is, the implementors point of view on a certain variable can be a different one than the callers point of view, which can justify a different name - which is exactly what gnasher729 repeated in his answer.
    – Doc Brown
    Oct 6, 2022 at 18:14
  • @DocBrown if the implementers POV differs from the callers, that is a problem to be fixed, or the spec made clear. Not something to be covered over.
    – user949300
    Oct 6, 2022 at 18:41
  • @user949300: no, thats not a "problem" but quite normal. The POV of a caller of a function has a different level of abstraction and should not know about how the internal implementation looks like. The POV of an implementer is obviously a different one. That is what function design is all about.
    – Doc Brown
    Oct 6, 2022 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.