OutSystems: Let’s talk about a naming convention

So, quick introduction first. OutSystems. Low-code. Done!

Very quick indeed right? Well, introducing OutSystems is not the goal of this article but rather, I want to touch on one aspect in using it that I think can still be improved — naming conventions.

Well, OutSystems already has their recommended naming conventions listed here. One thing I believe is lacking in this are the conventions related to variable names. In fact, based on my experience in the past few years developing in OutSystems, I found that having naming conventions for variable names will be beneficial. This is why I came up with my own version which I’ll be sharing with you in a bit.

Text can be visual cues too

Before we delve on my proposed naming convention, let me answer a question that most people will probably be asking right about now: Why?!

In the action shown above, we have 4 variables. Two inputs, one local, and one output. They can easily be identified by looking at the variables’ respective icons. But, when you start using them in the action itself, these visual cues don’t really show up. At the very least, you’d have to cross-check it every time against the logic tree.

This is the kind of experience I wanted to avoid. That’s why I started thinking of defining my very own naming convention. I wanted everyone in our team to be able to understand the context of a variable just be looking at its name.

Or is it just a prefix convention?

So, with that out of the way, I present to you my very own naming convention for OutSystems!

Actually, it’s not really a full-blown naming convention. My proposal here is more on adding prefixes to variable names so their context can easily be understood.

Here’s the different prefixes I used for action variables:

  1. Input parameters — prefix with “In_”
  2. Output parameters — prefix with “Out_”
  3. Local variables — prefix with “Local_”

So in the above example, the action will look like this when this convention is used:

I started off with the above. Then, I realized we that can still expand this convention to cover screen action names as well.

  1. Normal actions triggered by page interaction — prefix with “Action_”
  2. Event handlers for web blocks — prefix with “Event_”

Here’s how it looks like for a sample screen:

Basically, that’s it. For anything after the prefix, I still follow the base naming convention defined by OutSystems. So for a button click action, instead of “SubmitOnClick”, I’ll name it as “Action_SubmitOnClick”.

As another benefit, the prefixes will also help you in sorting screen actions making it easier for developers to locate them in the tree.

Let’s close this

I understand that with this convention, there’s more typing involved. But in my opinion, I’d rather sacrifice typing a bit more characters to ensure an even understanding in the team in terms of code we write — or in this case, code we don’t write (Low code right?).

To anyone who has reached this point in this article, you may or may not use this convention. In fact, you may or may not like it. But if you do feel that it’s something that you can use or improve on, then great! But if you have any reservations or concerns, just feel free to leave your comments below. Hoping to hear from you!

A software developer trying to share his experiences to the world. Hoping to hear back and learn more from anyone willing to listen.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store