I was searching on Google about the difference between Method and function and I got two answers.
Method is non return type like below
void Method()
{
}
Where as Function is a return type like below
int Method()
{
}
There is no difference between these two terms.
Query - Which is correct or there is any third thing?
There is no difference.
In c# and java, you normally call them methods. in javascript and c++, they're normally called functions
either way, people will know what you mean
as for Answer 1, If I was a brand-new programmer, and I were asked to speculate on the difference, that answer 1 would probably be what I'd come up with. given the mathematical definition of function as a process where your input determines exactly your output
I think what you are really asking is what is the difference between a function and an action (both are methods) in C#.
The difference has to do with how void is treated: this explains it pretty well https://softwareengineering.stackexchange.com/questions/131036/why-is-void-not-allowed-as-a-generic-type-in-c
I'll post Eric Lippert's answer in full to save a click:
The fundamental problem with "void" is that it does not mean the same thing as any other return type. "void" means "if this method returns then it returns no value at all." Not null; null is a value. It returns no value whatsoever.
This really messes up the type system. A type system is essentially a system for making logical deductions about what operations are valid on particular values; a void returning method doesn't return a value, so the question "what operations are valid on this thing?" don't make any sense at all. There's no "thing" for there to be an operation on, valid or invalid.
Moreover, this messes up the runtime something fierce. The .NET runtine is an implementation of the Virtual Execution System, which is specified as a stack machine. That is, a virtual machine where the operations are all characterized in terms of their effect on an evaluation stack. (Of course in practice the machine will be implemented on a machine with both stack and registers, but the virtual execution system assumes just a stack.) The effect of a call to a void method is fundamentally different than the effect of a call to a non-void method; a non-void method always puts something on the stack, which might need to be popped off. A void method never puts something on the stack. And therefore the compiler cannot treat void and non-void methods the same in the case where the method's returned value is ignored; if the method is void then there is no return value so there must be no pop.
For all these reasons, "void" is not a type that can be instantiated; it has no values, that's its whole point. It's not convertible to object, and a void returning method can never, ever be treated polymorphically with a non-void-returning method because doing so corrupts the stack!
Thus, void cannot be used as a type argument, which is a shame, as you note. It would be very convenient.
With the benefit of hindsight, it would have been better for all concerned if instead of nothing whatsoever, a void-returning method automatically returned "Unit", a magical singleton reference type. You would then know that every method call puts something on the stack, you would know that every method call returns something that could be assigned to a variable of object type, and of course Unit could be used as a type argument, so there would be no need to have separate Action and Func delegate types. Sadly, that's not the world we're in.
For some more thoughts in this vein see
http://blogs.msdn.com/b/ericlippert/archive/2009/06/29/the-void-is-invariant.aspx
and
http://blogs.msdn.com/b/ericlippert/archive/2011/02/21/never-say-never-part-one.aspx
and
http://blogs.msdn.com/b/ericlippert/archive/2011/11/28/why-have-a-stack.aspx
There is no difference between the two terms. They are interchangable in terms of what they mean.
I've found that when dealing with unmanaged code(C/C++), people will refer to them as functions. But when dealing with managed code(C#/java), people will refer to them as methods.
This really depends on ones terminology. The first answer isn't wrong but some will not consider it 100% correct either, the use of the word function can tend to be where there is a return from the method.
So in an underlying method you can do:
void DoSomething()
{
int i = Sum(1, 2);
}
Then have a return method, which could be determined as a function:
int Method(int i, int j)
{
return i + j;
}
So to answer your question, neither is correct. It's how you interpret them as many developers do tend to vary what they say. VB.Net however, does use Sub and Function for methods so if you have come from a VB.Net background, you may refer to the return methods as functions.
In .NET the terms are pretty much synonymous, but in languages such as JavaScript, they may have slightly different meanings. An (js terminology) example would be how methods are typically object properties that contain functions.
You may also here the differences stated as functions are meant to be stand alone units of functionality whereas methods are defined as members of a class. In. NET, you will usually hear the term 'method' used more often than 'function' (however they do have, aptly named, 'anonymous functions').
There is another question on here regarding function and method differences that you may want to look at for additional detail.
Always thought it was Answer 1, with which I shamelessly, occasionally use them interchangeably anyway.
I've met something similar to Answer 1 in Pascal, where people called void methods procedures and methods with return type functions.
In C#, usually, both are called methods. The term function is usually reserved for delegates, which are usually divided into functions and actions - there you can find similar terminology to your Answer 1 again.
I have deliberately used the word usually so many times, because often people bring terminology from other languages, but what I wrote is something that I've encountered most often in printed C# literature like C# 4.0 Unleashed.
