Hi community,
I’d like to bring up a topic for discussion. In some projects I’ve worked on, I’ve noticed a recurring development pattern: the use of a dummy node (an empty assign) in conditional logic, particularly within IF statements. This approach is often used to avoid node intersections or simplify logic flow.
Before sharing my own opinion, especially since there are differing views within my current team, I’d love to hear your thoughts. Some see it as a clever workaround, while others consider it unnecessary or even harmful to code clarity (clean code).
So I’d love to hear your thoughts:
Thanks in advance to everyone who contributes to the discussion!
yes, i know the pattern and use it
to reduce cognitive load for someone looking at the code, I prefer to have a single dot "." instead of a word like "dummy". When it says "dummy", I always start reading it before realising it doesn't do anything.
I prefer to reorganise a flow to avoid it, but when that's not possible, I think it adds clarity to a flow, not diminish clarity.
There has been ideas open on the OutSystems site for a long time to give us a separate node type that only serves this purpose, that would be MUCH better, but I'm not holding my breath.
Hello.
I only use them when there is no better option, but every project will have at least a couple of them.
I've seen some projects where the description is an arrow to reduce the confusion (like Dorine mentioned).
If it is my own project, I may even create an empty action with a custom image instead of using a empty assign.
Do what makes your team more productive.
Hallo @Nivaldo Pereira ,
Observations from Reviewing Multiple Projects
When there is no agreement within the team
Some developers may assume the element (Component or Practice) is wrong and simply remove it.
This leads to inconsistency across the codebase.
When naming is not done properly
Poor or unclear naming makes it difficult to understand the actual purpose of the element.
As a result, it causes confusion and makes long-term maintenance harder.
It can sometimes cause issues, but it can also be useful
While it may add some complexity,
it can also help clarify the action flow and make the code more readable, reviewable, and auditable.
✨ Conclusion: The decision to use it or not should strike a balance between code clarity and simplicity, while ensuring the team has a shared agreement on standards.
It's a needed workaround, when you need to organize the lines.
but it should be considered a last alternative. Most of the times, it can be solved by refactoring it in a separate action and then you do not have the issue anymore.Of course, it still is needed (especially when you have big switch statements etc.)
I do like @Nuno Reis approach to create a custom actions with an image.
But tbf, I would love to see something built-in so we either can manipulate the line itself, or a built-in widget.
Hello,
Yes, I am using this pattern to make my flow more readable and avoid any intersections between flows.
I used to name it as dummy and write description its dummy assignment to make flow readable but I agree with @Dorine Boudry you have to stop and read description to make sure its dummy.
Hello.I have been used this pattern as well, but it's a last resort, when we cannot find a way to not have crossing lines in the code and really need to have all that code inside a same action.
Then when it's used we make sure that everyone can understand it's dummy, but also liked Nuno Reis approach!
Hello Nivaldo, hope all is well with you - we haven't seen each other for a while :)
I've seen and use this pattern on my projects as a way to improve code clarity. Like many have said here it's used as a last resort because of the trade-offs it requires. Basically as a downside it also does not help code quality as the empty assign may look at a glance that is doing something but it does enable us to get more readable graphs that don't cross lines in ways that are not easy to read.
Before going this route I usually ask if it makes sense that the code where it is be isolated as a separate action - this usually makes it much easier to read and it's common on code that is inside a for loop. That said I have come across other team leaders that think that going into another level adds too much to the complexity of the module. The old consulting saying is true here - "it depends" :D
I would certainly welcome if Outsystems gives us a routing node that looks different than an empty assign but I don't find it a priority. For now I'm happy with the "hack" of the empty assign. Didn't think to make it as official as Nuno Reis with a custom action and icon, that is a nice tip.
Just to say that part of the discussion was taken in LinkedIn
It's very normal when we are dealing with complex logic, sometimes we need to add this empty assignment for better understanding. I also used same also sometimes I created empty logic with custom blank icon that will also help us to make our code more understanding
I believe that using this feature is a personal thing that can really help in many cases with organizing logic, as long as it's agreed upon in advance with the team to clarify the use during project development. However, in Ai Mentor, this feature is computed the same as any other, which can lead to technical debt; therefore, its use should take this into account.
It is not real technical debt as you don't need to refactor to improve performance.
It can also be marked as false positive once and forgotten.
Dear all, this seems to be a common thing reading all the answers here. Personally, I have never used something like this before, and I couldn't think of a use case. But I'm curious to learn more and wonder if one of you could give me a concrete example when you apply such a pattern?
Thank you.
You'd rather read this?
or this?
Interesting. I think I'd personal rather have that as:Makes more sense to me in general but it would depend. This is not to say that there are not use cases for the dummy assign - there usually are if you think that the tradeoff to isolate the code more into other actions isn't there. If you need this iterated on a for it's an example of were you may need to decide if you will want more actions on your module or a quick assign to make it more readable without having another layer.
I also use this frequently for a nice flow of IF's or for an extended Case structure. But I call it NOP.
Hi All,
I've used this dummy pattern once or twice in my project but I always wonder 🤔 isn't there any better way to avoid this or if this is the correct approach.
Even I asked my team leads, they suggests we can use it to if there isn't any other condition to redirect the flow.
But still I'm really curious and glad to be part of this discussion.
Looking forward for more replies.
Regards
Ayushi
Dummy node is used according to the rules created in the project. In order to make it easier to understand in appearance, the name is marked with a symbol.
However, the case where a Dummy node is required is already complex and may become more complicated in the future, so I think it is better to refactor it with another action.
Absolutely only I name it 'NONE' since dummy can also mean that it contains a dummy assign value or something like that, so 'dummy' wouldn't be accepted by me (-:
These 'empty assigns' must be used to keep your logic readable and it's a big plus regarding maintenance where that always comes in when you'll have an issue and need all the time you'll can get.