What does a procedural program code look like?

[Maximilian]

With object oriented stuff you can look at the code for individual classes that make up the objects, with procedural... is it just like one massive page full of code that you scroll down or what?

 

[owensdj]

Procedural code in modern languages can be broken up into multiple functions/methods/procedures that can be in the same source code text file or in multiple files. The main program is usually relatively simple because it's implemented by breaking down much of the logic of the program into calls to procedures. The same approach is used in implementing those procedures until you get procedures that are relatively simple to implement.

 

[Maximilian]

So in an object oriented language we have something like:

public class weebaws
    {
        Random aRandomGenerator = new Random();
        
        int aNumber = aRandomGenerator.nextInt();
    }

But in a procedural language the same thing would roughly be:

int aNumber = nextInt();
        
public int nextInt()
{
            //all the stuff to make a random number goes here
}

Is that the jist of it?

 

[Cogman]

*deleted* I said dumb things.

 

[owensdj]

Maximilian yes that's pretty much it. Procedural programming is about breaking down the program into procedure calls. Object-oriented programming is about breaking down the program into objects, which have procedures and data inside of them.

 

[It's Not Lupus]

When should one be used over the other?

 

[Merad]

Is that the jist of it?

Well, your examples are a bit deceptive, because in a procedural language like C you typically don't have executable code outside of functions. If you want a better example consider these equivalent Java and C programs:

class MyApplication
{
  private int a;
  private int b;
  
  public static void main(String[] args) {
    new MyApplication.run();
  }
  
  public void run() {
    doStuff();
    doOtherStuff();
  }
  
  private void doStuff() {
    this.a = 1;
  }
  
  private void doOtherStuff() {
    this.b = 2;
  }
}

typedef struct
{
  int a;
  int b;
} ApplicationState;

void doStuff(ApplicationState* as)
{
  as->a = 1;
}

void doOtherStuff(ApplicationState* as)
{
  as->b = 2;
}

int main(int argc, char* argv[])
{
  ApplicationState state;
  doStuff(&state);
  doOtherStuff(&state);
  return 0;
}

 

[MrDudeMan]

class MyApplication
{
  private int a;
  private int b;
  
  ...

  private void doStuff() {
    this.a = 1;
  }
  
  private void doOtherStuff() {
    this.b = 2;
  }
}

Isn't the use of 'this' superfluous in this context? I know some people prefer it stylistically, but I don't think it's actually required here. Sorry for the tangent, but I figured the me and the OP could learn something at the same time.

 

[Merad]

It's only required when there is a local variable with the same name and you need to use "this" to specify the field vs the local variable. You probably see it most in constructors:

MyApplication(int a, int b) {
  this.a = a;
  this.b = b;
}