Functions should be small

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” — Robert C. Martin 

I'm wondering how often people consider this in visual programming. I started in written programming, and this was a principle I've tried to follow. You wanted to name a function according to what it did, and it should only do what the name said it did, and nothing else, and it should only do one thing.

Visual programming allows you to kind of make a flowchart within a function (server action), which means you are doing all kinds of stuff inside that function, with all the problems that can lead to. Side effects are a huge issue. You change something inside that "flowchart" function, and it might have rippling effects all over the place that are hard to track down.

Thoughts?

mvp_badge
MVP

Hi Joseph,

Good question. These principals you mention are generic software development principles, and as such also apply to OutSystems visual programming.

  1. So ideally a function does one execute one task, but a task can be decomposed, like in high code a task can take you to code multiple code lines, in OutSystems you might need to have an action flow of multiple actions to complete the task.
  2. Side affects should be avoided by not using session related data directly in your actions, instead pass them on as input parameters. This is also a requirement if you test automate your actions using frameworks like BDD framework. Examples of built-in functions you should avoid directly use in your actions are GetUserId(), GetDate(), etc. 
  3. Regarding code complexity, the following should be considered:
    1. Keep the LOC (lines of code) as small as possible, in OutSystems keep the number of actions / tools you use in an action small
    2. Cyclomatic Complexity, the more IF and SWITCH statements in an action, the more complex it will be to test all possible execution paths (https://en.wikipedia.org/wiki/Cyclomatic_complexity)
    3. Number of in and output parameters, the more you have, the more complex your action
  4. Proper use of comments (documentation of your code)

The above 4 parameters define the maintainability of your code, also called the maintainability index.

Code analysis tools like OutSystems Architectural Dashboard and COTS applications like OmNext and BonCode, help you analyze this and will report if your code is to complex.

Kind regards,

Daniel

Daniel,

Thanks for your very thorough response. Lots of good thoughts in there that I'd like to discuss, but haven't had time to adequately address yet. I hope to come back and engage more.

I'll just make one comment about using GetUser() and GetDate(). These are critical for auditing purposes and security. If you are developing in React, and you pass in a UserID or Date as a variable, you are very often exposing these to a crafty user who could change these values in a post response to gain rights they shouldn't have or to forge an important date. Rather than trust an exposed server action to these variables in particular, I prefer to use GetUser() and GetDate() inside the ServerAction so they cannot be spoofed. Thoughts on this?

Thanks,

JM

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.