How do you name single output functions?

The matlab style book reccomends to name single output functions like their output, which is consistent with the MALTAB functions...

I dont like this very much, because I want the variable of the output of my function be called like the output...

How do you name your single output or single output function?

I would probably use something like

function result = calculateResult(input)
% calculateResult calculates Result ;D
end

altough I dont like it that much

Answer 1

[Jan]

I use CamelCase for my funtions to reduce the danger a collision with toolbox functions of Matlab. For frequently used functions, compact names are nice. A leading "Calculate..." would introduce too much redundancy, because most functions calculate something. Compare:

CalculateMean(CalculateSin(CalculateLinSpace(0, 2*CalculatePI, 1000)))

with

mean(sin(linspace(0, 2*pi, 1000)))

How the output of a function is called, does not matter, when the function is called. Then the code of the function is not visible and the naming does not influence the usability.

Sometimes, I use the name of the procedure, sometimes the name of the output, and sometimes I add an initial "Set", "Get", "Write", "Read" etc. An example for different approachs:

MD5  = GetMD5(File)
MD5  = MD5Hash(File)
Hash = MD5(File)
...    

Some fixed styles for choosing names of functions and variables are useful. But as long as you keep the overview and hte names do not get too long or too cryptic, it remains a question of taste. Then spending time and energy in the naming conventions is a wasted optimization.

On the other hand I'm using conventions for all names of variables:

• sulkingCamelCase for internally used variables, CamelCase for onput and output.
• All names in singular, trailing "List", "Vec" etc. if it matters, that they are arrays.
• Leading "is..." or "do..." for logical flags.
• "n..." is a number of elements or objects, "i..." is a loop counter.

This reduces the chance of e.g. confusing "nFile" and "nFiles" anywhere in the code. In opposite to this, I see less problems with confused names of functions.

[Maximilian Schönau]

Thank you!

I guess I won’t use calculate anymore, and think of a different Name for the same thing within the function it is calculated...

Answer 2

[madhan ravi]

result = @(in) in.^2;
result = result(1 : 10)

result = 1×10

1 4 9 16 25 36 49 64 81 100

[Maximilian Schönau]

Functions having the same name as their result is only possible with functions handles like you did. Also that is not practical cause the function gets overriden

[madhan ravi]

 function result = Result(in) % perhaps?

[Walter Roberson]

Functions having the same name as their result is only possible with functions handles like you did.

Not true. For example,

sum = sum([1:5; randi(10,1,5)])

sum = 1×5

3 8 13 13 6

sum is not a function handle, it is a full function, but you have successfully used it both as a function name and as the name of a variable.

Also that is not practical cause the function gets overriden

What would your ideal interface be, that would permit you to distinguish between calling a function named result, vs using or indexing a variable named result?

Who would your ideal readers of your code be, that they would never be confused between whether result was referring to a function or a variable?

x = result          %is that calling result or is it copying the variable named result?

[Maximilian Schönau]

Hi, I probably didn’t made it clear, but I was referring to the variable name within the function...

And a function declaration of

function mean = mean(y)

Would not be possible.

As to your last Statement, I would always write:

x = result();

I also do this when calling methods with no inputs on my class.

Answer 3

[Steven Lord]

function result = calculateResult(input)
% calculateResult calculates Result ;D
end

I have some feedback on this.

First, the identifier input already has a meaning in MATLAB so I wouldn't use it as a variable name.

Second, I dislike that function name because it's so bland. It offers no hint of what the function does. "calculate" and "Result" in this context are both plain filler words. In my opinion reading the name of the function should give me a reasonable idea of what the function actually does and ideally I should not need to read its help text or its documentation unless I need details about some specific nuance of the function. [Yes, I know that not all functions in MathWorks products satisfy this. I did use the word "ideally" in my description. Plus we've learned a bunch about designing our software over the past couple decades.]

Think of it like Burger King, Kentucky Fried Chicken, or Pizza Hut. Even if you've never heard of one of these businesses before, likely you could guess just from the names what they are (restaurants) and what they sell (burgers, fried chicken, and pizza respectively.) As a MATLAB example, consider the islocalmax function. Without reading that function's help text or documentation, what would you guess it does?

Third, it shouldn't matter what you name the output variable inside your function. Ideally the user of your function should not care how the sausage is made, just that the sausage they ordered is the sausage they received. [The health inspector should care, but in this metaphor the health inspector is played by the white-box tests of your function. And even the health inspector probably shouldn't care what nicknames you have for the pieces of equipment in your kitchen unless you call the meat grinder "The Salmonella Factory."] There's nothing tying the name of the variable in your function that you assign as the first output to the name of the variable to which that output is assigned in your user's code. There's effectively no difference between (using your calculateResult function)

y = calculateResult(1:10)

abracadabra = calculateResult(1:10)

qwerty{1} = calculateResult(1:10)

% Assuming the caller called sin on one of the above
z = sin(calculateResult(1:10)) % the output of calculateResult is stored in an unnamed temporary

[Maximilian Schönau]

Hello, thank you for your answer!

result = calculateResult(input)

was more a general proceeding of how o would name my function, if the function would calculate the mean of an array I would do something like:

function mean = calculateMean(array)

My real problem is that I don’t like writing calculateMean, and would also prefer Mean as my function name. Your argument of „the user doesn’t care how it’s made“ was a good one. But it still annoys me, that the „perfekt“ variable name is a different one in the function where it is made, since the function has already the name. The function calculateMean would therefor be:

function m = mean(array)

Using m for mean within the function mean would annoy me very much if mean was a big function.

I therefor wanted to hear opinions, of how other guys handle this problem, or if they just use they preferred variable name as the function name, and within the function call their result differently...

[Steven Lord]

Using m for mean within the function mean would annoy me very much if mean was a big function.

So don't use it. Use a variable name that makes sense. However, you just can't use an identifier as both a function and as a variable in the same workspace because it leads to ambiguity. If your function was "function mean = mean(x)" then what would mean(5) refer to if executed inside that function? Would it be the fifth element of the variable named mean or would it be a recursive call to the mean function with the input x containing the value 5?

That recursiveness may not resonate with the mean function, but would you define a function "function sort = sort(x)"? If that were performing a quicksort sort(5) could refer to a pivot or to sorting a 1-element partition of the data via a recursive call.

Though I'd also be cautious because you said "a big function". How big is "big"? My rule of thumb when I'm creating test functions is that if the test function is longer than about a screen or maybe two it may be trying to do too much and I should think about whether I can break it up into more focused pieces or convert some part of it into a helper (which may also help with code reuse, writing a common utility once and using it repeatedly.) IMO the longer the function is the harder it is to understand, debug, optimize, and test. [Note when I say test function I mean an individual four phase test; a test file I create likely contains many test functions.]

[Maximilian Schönau]

I hope I did not sound, as if I find the separation of a function name and it’s output not necessary, it obviously is.

I am just a bit annoyed, that using the function mean as an example, I have to use a variable within the function mean, that will be the output and therefore the mean, but I am not allowed to call it that way.

Again, I don’t know how you could avoid this problem in a smart way, that was the reason I asked this question here :)

I found out, that calling my function mean „calculateMean“ so that I am free to use mean as an variable in that function probably is in most cases not the best solution.

[Walter Roberson]

I have seen programming languages in which the method to return a value was to assign to a variable with the same name as the function. However, the name could not otherwise be used as a variable inside the program, and could not be indexed. So for example it would have been valid to do the equivalent of

double mean(double x) {mean = sum(x)./numel(x);}

However, such languages have challenges. For example,

double mean(double x) {mean = 0; mean = mean + mean(1) + mean(x./2);}

Is the mean(1) indexing? Is it function evaluation?

double mean(double x) { memzero(&mean, sizeof(mean)); }

is memzero being passed the address of the output variable for the function, or is it being passed a pointer to the function ?