Simple question, but I often hear these three terms defined with such ferocity, but which have been known to me to mean different things over the years.

What are the "correct" definitions of "Procedures", "Methods", "Function", "Subroutines", etc?

  • 5
    you forgo "routine" – mefisto Apr 3 '13 at 13:51
  • 1
    @teresko: I think "subroutine" is more common. – mk12 Jul 7 '13 at 21:06

I'm going with a different answer here: practically speaking, there's really no difference, with the slight exception that "method" usually refers to a subroutine associated with an object in OO languages.

The terms "procedure, function, subroutine, subprogram, and method" all really mean the same thing: a callable sub-program within a larger program. But it's difficult to come up with a definition that captures all variant usages of these terms, because they are not used consistently across programming languages or paradigms.

You might say a function returns a value. Well, the following C function doesn't return a value:

void f() { return; }

...but I doubt you'd find anyone who would call it a procedure.

Sure, in Pascal, procedures don't return values and functions return values, but that's merely a reflection of how Pascal was designed. In Fortran, a function returns a value, and a subroutine returns multiple values. Yet none of this really allows us to come up with a "universal" definition for these terms.

In fact, the term "procedural programming" refers to a whole class of languages, including C, Fortran and Pascal, only one of which actually uses the term "procedure" to mean anything.

So none of this is really consistent. The only exception is probably "method", which seems to be used almost entirely with OO languages, referring to a function that is associated with an object. Although, even this is not always consistent. C++, for example, usually uses the term "member function" rather than method, (even though the term "method" has crept into the C++ vernacular among programmers.)

The point is, none of this is really consistent. It simply reflects the terminology employed by whatever languages are en vogue at the time.

  • That's precisely what I thought the answer was. (I should have added "subroutine" as another variant in hindsight.) Can I ask: Why wouldn't you find anyone who call that C function a "Procedure"? Because it's technically incorrect, or because the term "procedure" is currently out of vogue? – Django Reinhardt Nov 23 '10 at 19:42
  • 7
    C programmers use the term "function" simply because the designers of C used that term. – Charles Salvia Nov 23 '10 at 19:54
  • 16
    Let's not throw the baby out with the bathwater. Just because the terminology is not used with full consistency, doesn't mean that the different terms don't have different meanings. @Bruce's and @Frank's definitions are widely recognized, not idiosyncratic. The fact that the meanings are not universal is important, but it doesn't justify the leap to "practically speaking, there's really no difference". (@Django) – LarsH Nov 23 '10 at 23:33
  • 9
    Kind of dual to C++, which calls methods "member functions", Java and C# call functions "static methods". – Jörg W Mittag Nov 24 '10 at 1:28
  • 2
    Bruce's answer is definitely the one you should go for if you're new to programming. His definitions will be absolutely correct, 99% of the time. But I was looking for more of a technical/theoretical answer. Sometimes newer programmers know only their own domain, and insist that is all there is. In reality there are programmers working today who still use older languages, and who are not "wrong" for using different definitions. That was what I was most interested in. – Django Reinhardt Apr 12 '11 at 18:37

A function returns a value, but a procedure does not.

A method is similar to a function, but is internal to part of a class. The term method is used almost exclusively in object-oriented programming.

  • 8
    Not exactly internal. A method is any function or procedure that is part of a class. – Scott Whitlock Nov 23 '10 at 17:48
  • 8
    So a "Stored Procedure" in SQL doesn't return any values? What about a "Procedure" in something like Pascal? Are your definitions based on current trends or should they be considered universal definitions? Thanks! – Django Reinhardt Nov 23 '10 at 19:10
  • 3
    @Django: In Pascal a procedure cannot have a return value, and a function must have a return value. In some other languages, the terminology may be used more loosely. – Bruce Alderman Nov 23 '10 at 20:04
  • 1
    FWIW, FORTRAN had SUBROUTINEs and FUNCTIONs from the early days, the difference being that a SUBROUTINE didn't return a value. I don't remember about ALGOL, which Pascal is descended from. – David Thornley Nov 23 '10 at 22:42
  • 2
    @3p1c_d3m0n It's certainly true that function fulfills both roles in JS, but JS functions do all return. When a return statement has no value, the value is implicitly undefined. When a return statement is absent, the interpreter adds an implicit return statement. Esoteric, maybe, but it is consistent with the definition given here. This is why var x = function() {}(); is legal in JS; if not for implicit returns, this would need to be an error, as it would be in Pascal. – Semicolon Nov 8 '15 at 5:25

A function is something that takes a bunch of inputs and returns one or more values. If the returned values are entirely determined by the inputs, and the function doesn't have any side effects (logging, perhaps, or causing state changes outside itself), then it's called a pure function.

A procedure is a function that doesn't return a value. In particular, this means that a procedure can only cause side effects. (That might include mutating an input parameter!)

A method is a function that closes over a set of variables, that is, a closure. It takes zero or more input parameters, has access to this set of variables, and returns zero or more values. In OO languages these methods are attached to objects or classes.

In most mainstream OO languages, those closed-over variables are called the member fields, or instance variables, of an object. A method can be a pure function, an impure function or a procedure.

The latter definition leads to the object = struct + closures correspondence.

  • 5
    So an object is a collection of variables and a collection of closures over these common variables. Basically, object-oriented languages have always had closures and nobody knew? Interesting view! +1 – Giorgio Jan 4 '13 at 23:45
  • 1
    I do not believe most methods close over anything. foo.doSomething() is not parameterless. It has one parameter (the object foo) with given with some syntactic sugar. A closure would be able to reference its object without needing such a parameter. That's not to say methods can't be closures, just that most are not, and that being OO is not sufficient for a language to support closures. – 8bittree Aug 14 '14 at 20:43
  • 3
    foo.doSomething() closes over the foo variable. Any statement in doSomething can access foo through this or self, depending on your language. This is the very definition of "close over". Classes close over their member variables, therefore (ignoring "what is OO"), OO is sufficient. This is pretty well-known in the literature... – Frank Shearar Aug 15 '14 at 8:47
  • 1
    Er, no. See that little foo. at the front of foo.doSomething()? That's you passing doSomething() a parameter. Just because it's not in between the parenthesis does not mean it's not a parameter. The this or self inside the method is simply syntactic sugar for referencing that parameter. – 8bittree Jun 9 '16 at 16:54
  • 2
    ...I singled out "impure function" for ridicule because it cannot necessarily be distinguished from a "procedure" or "method" by your definition. Nor can a "method" and "procedure" be clearly distinguished, since a method attached to a class may use none of its instance variables, or the class need not have any instance variables, but it would still be called a "method" in OO languages (and it's container would still be called a class). There are no generally accepted clear distinctions between these words. – Steve Feb 7 '18 at 19:40

Bruce has a good answer. I would add, semantically:

  • A procedure should "do something" to the arguments or cause some other side effect (e.g. printf)
  • A function should (a) answer a question about the arguments, or (b) compute a new value based on the arguments
  • A function method should answer a question about the state of the object
  • A procedure method should change the state of the object
  • Great answer! Just one tiny addition: A procedure should "do something" to the arguments - or cause some other side effect (e.g. printf). – Allon Guralnek Nov 23 '10 at 18:05
  • 1
    @Allon Note that printf returns a value - the number of characters printed - so it is technically a function. – Sjoerd Apr 12 '11 at 20:09
  • @Sjoerd I don't agree that printf is a value. It had a specific side effect outside its invocation scope: namely I/O to whatever the standard output its supposed to be. Even though, Scott was not explicit this distinction, in functional programming functions are not supposed to have side effects, and should be able to answer questions as if you had the actual data it returns. – Alan Aug 14 '14 at 17:17

good detailed answers above; the short story is that they'll all flavors of subroutines; what is meant by each term will vary according to the programming language context

in general, functions return a value, but they don't have to

methods are a generic OOP terms at present

in SQL, stored procedures have outputs but typically only return an error code, while user-defined functions must return a value (which may be a result-set)

again, the precise difference between these terms depends on who you're talking to!


80% of proficiency is directly related to familiarity with nomenclature,

95% of productivity is the ability to identify what is useful at the moment despite the terms used to describe it

I pretty much prefer to call them all methods in c# except back when I used MSSQL we had sproc's, but of course now we use Postgres and they are called functions.

  • 16
    83.5% of all statistics are made up on the spot ;-P – Django Reinhardt Jan 5 '13 at 5:22
  • 1
    I have to admit, I get nervous when I hear someone throwing around the term "method" when working in a non-OO language. It seems to be heavily correlated with running into non-idiomatic code. – Racheet Jan 17 '14 at 15:54
  • I use 'Method' when referring to C code because many OO programmers I deal with have a mental breakdown on hearing the terms procedure or function. For fun, if I really want to mess with them, I might interchange the terms randomly. Its not good, kind of like inviting a poltergeist into you home... :) – mattnz Jul 7 '14 at 1:46

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