What is procedure?

A procedure is a named block of code that carries out a specific set of steps. It groups related instructions together so you can run them whenever you need, without rewriting the same code each time. In many programming languages it’s also called a subroutine or function (especially when it doesn’t return a value).

Let's break it down

  • Name - a label you give the procedure so you can call it later.
  • Parameters (optional) - values you pass into the procedure so it can work with different data.
  • Body - the actual list of commands that the procedure executes.
  • Return (optional) - some procedures give back a result; others just perform an action and finish.
  • Call - the place in your main program where you ask the procedure to run.

Why does it matter?

Procedures let you write code once and reuse it many times, which saves effort and reduces mistakes. They also make programs easier to read because you can hide complex details behind a simple name. This organization helps you find and fix bugs faster and lets multiple people work on the same project without stepping on each other’s code.

Where is it used?

  • Desktop and mobile apps (e.g., button‑click handlers)
  • Web development (server‑side scripts, API endpoints)
  • Game engines (physics updates, AI routines)
  • Databases (stored procedures that run inside the DB)
  • Embedded systems (control loops for hardware)
  • Any language that supports functions/subroutines, such as C, Java, Python, JavaScript, Ruby, Pascal, etc.

Good things about it

  • Reusability: Write once, use many times.
  • Modularity: Break a big program into manageable pieces.
  • Readability: Clear names describe what the code does.
  • Maintainability: Change the logic in one place and all calls get the update.
  • Testing: You can test a procedure in isolation from the rest of the program.

Not-so-good things

  • Overhead: Each call adds a tiny performance cost, which can matter in tight loops.
  • Complex flow: Too many nested procedures can make the execution path hard to follow.
  • Side effects: If a procedure changes global data, it can introduce bugs that are hard to track.
  • Misuse: Over‑splitting code into tiny procedures can lead to “procedural fragmentation,” making the program harder to understand.
  • Recursion limits: Procedures that call themselves can run out of stack space if not designed carefully.