Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I learned to program, I learned Object Oriented Programming very early on. For a while, I blundered around with my beautiful hammer, trying to use it for everything, partially because I had no idea how to solve problems any other way. As I read more, I began to realize you need to use the right tool for the right job, and I quickly realized I had no other tools because I'd never learned any other style! I'm working on functional programming, and there are plenty of good books and articles about it. But what's a good way to learn procedural programming the right way?

I have a basic idea of how to make global variables and pass state to functions, but I want to delve deeper into procedural code. I know most of the time people have to learn the other way, and procedural code is often bashed around for being unmaintainable, but I want to learn it anyway so I have more ways of approaching a problem. OOP may often be a 'better' choice, but right know its the only thing I know, and I want to branch out.

I know procedural code was virtually the only style available for programming for many years, so most books don't say "we're going to teach you procedural programming!" and instead just say they'll teach you how to program, and the procedural is assumed. Those people can just find books that have OOP in size 72 font on the cover and know that's what it teaches. But I'm trying to go the other direction and feel a little lost...

How did you learn procedural programming? Which books/languages do you recommend? Are there any important tips to learning the right way to write procedural code so its as maintainable and beautiful as possible? What tips would you give an OO junky as to how to write awesome procedural code?


migration rejected from May 16 '15 at 22:14

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by Ixrec, gnat, durron597, Snowman, GlenH7 May 16 '15 at 22:14

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Ixrec, gnat, durron597, Snowman, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

It may also be of value to learn functional programming if your extending your toolkit. Procedural has it's use in C/C++. Functional has it's use in PHP, python, ruby, perl, javascript, F# (and haskell, ML, LISP etc). As for learning procedural code, read books on C. Procedural is the only way in C. – Raynos May 12 '11 at 13:08
@Raynos : you can always achieve some level of Object Orientation through struct and function pointers, but I digress... Some concepts of OO are useful and applicable to procedural, although not implemented the same way they still retain their potency in making code easier to maintain and easier to test. Global Variables are not more useful in procedural than they were in OO for example. OO was an evolution of Procedural and just because a language does not fully support the whole feature set of OO does not mean the wisdom attained must be completely ignored. – Newtopian May 12 '11 at 13:53
@Newtopian I agree there's nothing wrong with procedural code. I would personally frown upon OO emulation in C with structs and function pointers. – Raynos May 12 '11 at 14:09
Write some assembly. Or rather, lots of it. – user1249 May 12 '11 at 14:31
@Raynos, true, I should have separated the two parts as different comments. There is a fine line between getting the good common sense out of what OO thought us and trying to make everything into OO whatever the cost. This line I what I perceive to be the essence of CrazyJuggler's question, Jimwise's answer pretty much sums it up :-) – Newtopian May 12 '11 at 14:56

11 Answers 11

The main thing to keep in mind is that good practice in procedural code is very similar to good practice in OO code, you just have slightly different tools to get there with.

You should still be thinking in terms of building your program out of clearly thought out and well-isolated data types with clearly defined sets of operations on each one -- the difference is that you will now be thinking in terms of data types and procedures, not objects with methods.

In general, though, if it's a code smell in OO programming, it's a code smell in procedural code, too, and if it's a good idea in OO, it's a good idea in procedural programming. This includes:

  • encapsulating data in types, and only accessing the fields of these types through well-defined operations.
  • developing related code together, and clearly defining the interface between that code and the rest of your program as a set of primitive procedures on that data type
  • avoiding global data
  • avoiding assumptions about the inner structure of data anywhere but in the implementation of the primitive operations on that data

OO languages have given you a powerful tool for thinking about this type of encapsulation, (along, in most cases, with a lot of baggage). Do your best to keep these ideas of encapsulation when writing procedural code, even if the language won't force you to do so in the same way.

+1 An excellent example of encapsulation in procedural programming is the FILE struct. It is not meant to be created or modified by anything other than the file functions. – Michael K May 12 '11 at 14:20

If you havn't read the C programming language yet then I recommend you read that book.

It's a great introduction to C and learning C is a great way to learn procedural code.

I havn't read C traps and pitfalls myself, but this should show you good procedural code patterns and show you shouldn't write bad C code.

Note that there is a lot of overlap between good procedural code and good OOP code. In terms of learning new techniques to apply to OOP code, you'll learn more from the functional paradigm.

Although if you havn't learned C yet, it's a must. Learning a "low level" language like C bring a lot then just a better understanding of procedural languages. C teaches you a better understanding of hardware and that's an important thing to learn.

+1, good, clean C code is beautiful and very instructive. unfortunately, it seems to be a dying art. – Javier May 13 '11 at 1:38

You already know procedural code -- it is what you do inside a method for the most part. Generally, if it is a code smell in OOP, it is probably something procedural.

What you probably want to look at is functional programming, that is getting more and more useful and is a constructive way to get past some of the downsides of OOP and lets one make beautiful and maintainable non-OOP code.

Commenters: comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this question with others, please use chat. See the FAQ for more information. – user8 May 12 '11 at 16:58

In contrast to what other posters say here I maintain that it is not true that "procedural is the only way in C", for example.

One can of course write object oriented code in C. It's just that one does not have syntactic support for doing so. But this should be no obstacle to soemone like the OP who claims that he can think OO only.

A short list of Java language concepts and how they could be implemented in C:

class          struct
member         struct member
class member   variable with global scope
method         function that takes a pointer to a struct as first argument, 
               maybe dispatched via some kind of a virtual function table
interface      struct with vft that extracts if-method implementations from "class"
static method  global function
object         struct living in the heap
reference      pointer (through malloc)
exception      setjmp/longjmp (?)
I do not shy away to add that OO programming is merely a further devloped procedural programming. But OO people sometimes like to evoke the impression that before OO there was some Dark Age and they invented something really new. – Ingo May 12 '11 at 13:55
@Ingo OO is a concept of objects. You just don't have objects in C, in C you have pointers and data. It's different. – Raynos May 12 '11 at 15:19
@Raynos: You don't need access specifiers for OO. Case in point: Python, where encapsulation is by convention, not contract. – Jon Purdy May 13 '11 at 1:31
@Raynos, now I see where you are getting at. Of course, it is possible to write non OO C-programs (surprise!) by not adhering to OO principles. But my claim was: it is possible to adhere to the OO principles without the language supporting it explicitely. After all, in Java and C# etc. one is not forced to program OO, too. – Ingo May 13 '11 at 9:01
to all who think you can't write OO in C, remember that the original C++ compiler, cfront, translated the code to C to be compiled. – gbjbaanb May 13 '11 at 9:48

You don't need to learn procedural programming separately from object orientation. OOP is more of an organization of procedural programming- when you get right down to it, the contents of your member methods are procedures. OOP-supporting languages just write boilerplate procedures for you- it's perfectly possible to write object-orientated C, it's just a chore. Effectively, if you know OOP, there's no real reason to learn procedural code as it commonly exists- they're just re-writing the systems underlying what you already do. This isn't like functional or logical programming (PROLOG) compared to object orientation.

Consider malloc and free versus the garbage collector (or RAII). You haven't actually changed what's going on- heap allocation and appropriately-timed deallocation- all you've done is write free yourself instead of using a pre-provided system to free it for you. That hasn't changed any underlying algorithms or changed the way that you think about, well, anything. The appropriate times for heap allocation versus stack allocation are identical.

Of course, you could be confused by languages like Java where you can't allocate objects on the stack or primitives on the heap. This is confusing because the fact that something is an object, not a primitive, is irrelevant to it's intended lifetime, along with a bunch of other needless restrictions that are irrelevant to objects or object orientated programming.

+1 for mentioning declarative logical programming like PROLOG – Raynos May 12 '11 at 15:22

I have to ask whether you've really learned object oriented programming. My experience is that most people who begin with object oriented programming languages end up coding in a procedural style with small amounts of objectness. I suspect its not really possible to grasp the ideals behind OO without first grasping proceduralness. The fact that you are using classes/methods/etc does not mean that you are really following the principles of OO.


Simply setup a home project for which you'll use a language that doesn't implement OOP, like C.

Use the same logic when you want to do functional programming and other paradigms.


If you know OO programming, you also know procedural programming. Procedural programming is what you do with static classes and static methods and static member variables. Take a problem and constrain yourself to strictly static classes and static methods. Is that a more challenging task? You bet!

You mention learning to use global variables. A global variable is a public static member variable, nothing more. Object Oriented programming has taken the best practices of procedural programing and baked them into the language. You can write well structured maintainable code in any language. You can also write poorly structured, unmaintainable code in any language.

Good luck with your learning.


Think of procedural programming as Step1, Step 2, Step 3 type of programming. Things happen in a specified order usually starting from the top and working down. The code and processes should be well defined and well thought out. Just because it's procedural doesn't mean it should be a pile of spaghetti code. (Does this term still apply to today)

Global Variables and Global Data should be defined at the top and used as sparingly as possible. Subroutines and Functions should be used and well defined.

Server Side Includes that contain work-horse type functions and subroutines should be developed, maintained in a code library, and used in place of copy and pasting the same code over and over again.

If you create a something in memory, you should destroy it when your are done with it.

oh, I've seen too much spaghetti OO code in my time to understand that nothing really changes. Procedural is often more well organised in my experience, simply because it's more obvious you have to spend some time keeping your design tidy. – gbjbaanb May 13 '11 at 9:51
OOP spaghetti is identical only with extra pointless class syntax surrounding the one method that gets used by 10,000 other tiny classes. – Erik Reppen Jun 15 '13 at 0:14

When I am learing a new techonology I follow a simple algorithm

  1. Get the overview
  2. Learing by doing

Take one small project (or some part of it) in OO and try change it into procedural code. For example

Report lastReport = new Report();
SaleData lastWeekSale = lastWeek.GetData();

change into

SaleData lastWeekSale = LastWeekGetData();  // SaleData is a kind of typedef

Imagine writing code where the entire program takes place in a single class. That's procedural code.

I'm not just kidding either, I've seen beginners write entire Java programs in a single class. OOP languages only enforce OOP to the extent that you have to wrap everything in a class declaration; they don't actually require you to write multiple objects.

As for when to do procedural programming instead of OOP, well if the series of steps can be broken down clearly without any persistent packages of data then objects are just overhead. For example, what is the "object" in a series of math functions? That's procedural code.


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