Using function arguments as local variables

Question

Something like this (yes, this doesn\'t deal with some edge cases - that\'s not the point):

int CountDigits(int num) {
    int count = 1;
             


        

Answer 1

1. As a general rule, I wouldn't use a function parameter as a local processing variable, i.e. I treat function parameters as read-only.

   In my mind, intuitively understandabie code is paramount for maintainability, and modifying a function parameter to use as a local processing variable tends to run counter to that goal. I have come to expect that a parameter will have the same value in the middle and bottom of a method as it does at the top. Plus, an aptly-named local processing variable may improve understandability.

   Still, as @Stewart says, this rule is more or less important depending on the length and complexity of the function. For short simple functions like the one you show, simply using the parameter itself may be easier to understand than introducing a new local variable (very subjective).

   Nevertheless, if I were to write something as simple as countDigits(), I'd tend to use a remainingBalance local processing variable in lieu of modifying the num parameter as part of local processing - just seems clearer to me.

2. Sometimes, I will modify a local parameter at the beginning of a method to normalize the parameter:

   void saveName(String name) {
     name = (name != null ? name.trim() : "");
     ...
   }
   

   I rationalize that this is okay because:

   a. it is easy to see at the top of the method,

   b. the parameter maintains its the original conceptual intent, and

   c. the parameter is stable for the rest of the method

   Then again, half the time, I'm just as apt to use a local variable anyway, just to get a couple of extra finals in there (okay, that's a bad reason, but I like final):

   void saveName(final String name) {
     final String normalizedName = (name != null ? name.trim() : "");
     ...
   }
   

3. If, 99% of the time, the code leaves function parameters unmodified (i.e. mutating parameters are unintuitive or unexpected for this code base) , then, during that other 1% of the time, dropping a quick comment about a mutating parameter at the top of a long/complex function could be a big boon to understandability:

   int CountDigits(int num) {
       // num is consumed
       int count = 1;
       while (num >= 10) {
           count++;
           num /= 10;
       }
       return count;
   }
   

---

P.S. :-)
parameters vs arguments http://en.wikipedia.org/wiki/Parameter_(computer_science)#Parameters_and_arguments

These two terms are sometimes loosely used interchangeably; in particular, "argument" is sometimes used in place of "parameter". Nevertheless, there is a difference. Properly, parameters appear in procedure definitions; arguments appear in procedure calls.

So,

int foo(int bar)

bar is a parameter.

int x = 5
int y = foo(x)

The value of x is the argument for the bar parameter.

Answer 2

It always feels a little funny to me when I do this, but that's not really a good reason to avoid it.

One reason you might potentially want to avoid it is for debugging purposes. Being able to tell the difference between "scratchpad" variables and the input to the function can be very useful when you're halfway through debugging.

I can't say it's something that comes up very often in my experience - and often you can find that it's worth introducing another variable just for the sake of having a different name, but if the code which is otherwise cleanest ends up changing the value of the variable, then so be it.

One situation where this can come up and be entirely reasonable is where you've got some value meaning "use the default" (typically a null reference in a language like Java or C#). In that case I think it's entirely reasonable to modify the value of the parameter to the "real" default value. This is particularly useful in C# 4 where you can have optional parameters, but the default value has to be a constant:

For example:

public static void WriteText(string file, string text, Encoding encoding = null)
{
    // Null means "use the default" which we would document to be UTF-8
    encoding = encoding ?? Encoding.UTF8;
    // Rest of code here
}

Answer 3

My team coding standard recommends against this because it can get out of hand. To my mind for a function like the one you show, it doesn't hurt because everyone can see what is going on. The problem is that with time functions get longer, and they get bug fixes in them. As soon as a function is more than one screen full of code, this starts to get confusing which is why our coding standard bans it.

The compiler ought to be able to get rid of the redundant variable quite easily, so it has no efficiency impact. It is probably just between you and your code reviewer whether this is OK or not.