I've learned so much about OO programming I have no idea how to write procedural code. What's a good way to learn?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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 (?)

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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();
lastReport.ProcessData(lastWeekSale);

change into

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

Answer 11

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.