Every IBM i developer has opened a source member, stared at a sea of cryptic variable names, and muttered something unprintable. We have all inherited codebases where X1, CUSTFLG, and TMP123 roam free like wild animals. And while that might have been acceptable in the 1980s, modern RPGLE deserves modern readability.

A clean naming convention is not just aesthetic. It is a productivity multiplier! Clear naming standards are essential if you are moving toward VS Code, Git workflows, or simply refactoring/modernising old program code.

Clear, simple naming standards become especially helpful when moving common subroutines into sub-procedures in service programs. Tame it at start of the Project, so it doesn’t go wild and bite you at the end.

Let’s explore why adopting CamelCase for variables and snake_case for subprocedures is one of the simplest, smartest upgrades you can make to your RPG coding style (imho of course).

🐪 CamelCase for Variables: Readability Without the Noise

CamelCase gives your variables a natural language flow. Instead of shouting in ALLCAPS or smashing words together, CamelCase lets your eyes glide across the code.

Things I really like (dare I say enjoy?) about using CamelCase:

• Instant readability customerName is simply easier to parse than CUSTNAME or CUST_NAM.
• Natural grouping of concepts orderTotalAmount tells a story. ORDTOT does not.
• Modern tooling compatibility VS Code, RDi, and code linters all play nicely with CamelCase.
• Fewer naming collisions Prefix based naming (CUST_, ORD_) becomes unnecessary when your names are descriptive.

For example:

dcl-s customerName     varchar(50);
dcl-s orderTotalAmount packed(9:2);
dcl-s isPreferred      ind;

Readable. Predictable. Maintainable.

🐍 snake_case for Subprocedures: Clarity Through Structure

Subprocedures are the building blocks of modular RPGLE. Using snake_case for procedure names gives them a distinct visual identity. Different from variables, different from files, and unmistakably procedural.

I like to make mine standout from other coding so I use the snake_case for instant clarity:

• Instant visual separation calculate_totals() stands out from calculateTotals or calculateTotalsAmount.
• Great for long, descriptive names load_customer_from_file() is far easier to scan than loadCustomerFromFile.
• Consistent with many modern languages Python, Rust, C, and others use snake_case for functions. Your RPG code becomes more familiar to new hires.
• Improves code navigation When scanning a module, snake_case procedures jump off the page.

What do you think?

dcl-proc calculate_totals;
   dcl-pi *n packed(9:2);
      orderId int(10);
   end-pi;

   // ... logic ...

end-proc;

Why This Combo Works So Well

Using CamelCase for variables and snake_case for procedures creates a visual hierarchy:

This separation means your brain does not have to guess what something is. The name tells you instantly.

My old brain needs these gentle nudges 🙂

I like this combo because new developers understand your code without tribal knowledge. When everything is named consistently, bugs stand out instead of hiding. Meaningful changes become obvious. Noise disappears.

Finally, to quote a century old adage: Your code becomes self-documenting, reducing the need for comments like // this variable stores the customer name.

RPGLE has evolved dramatically, and our coding habits should evolve with it. Adopting a simple, consistent naming standard CamelCase for variables and snake_case for subprocedures gives your codebase a modern feel, improves readability, and makes your future self and your team very happy.