After one external analysis and having the opportunity and the pleasure to work with new colleagues, that is always an opportunity to learn something different or see other points of view.
For the first time that I started to develop in OutSystems I had the experience that someone said to me and I saw in the code that the True of the if should be to the right. For me since the beginning we always try to make the happy flow to the bottom.
Even more strange, I saw experienced people from OutSystems partners companies teach like that, True flow to the right.
Now, here is a case that unfortunately (or actionaly is an opportunity for us to think about this) we don't yet have a manual on how to code in this company, what are the rules.
I asked why to the right? And actually why to the button, because OutSystems doesn't have the best practices to do code, or they have. For me to code from the top to the bottom is like writing this from the left to the right, but for the first time I got a different view.
The reason (this link was also included in a client document): https://leonardo-monteiro-fernandes.medium.com/a-code-style-guide-for-outsystems-97a923084159
Is this the unique source that someone talks about this?
I respect the idea a lot but what I said to the colleagues is that this is a point of view of one person and in the comments are people that don’t agree. Me neither specific in this points:
1 -“most important” to the right and if they are equal both go to the button like a Switch?! (never heard).
If the most important is to the right, if we have a lot of if’s the code is going to the right instead of the button (this is not correct).
The most important is the happy flow, so I’m developing to the right? So when he says: Guideline 1 — down is progress?! or doing code is like reading a book, I see some inconsistency. Now a foreach yes makes sense. The right goes to the right because I’m trying to create a circle and the happy flow is to close that circle, so True goes right, down, left until the foreach, the happy flow, is correct.
Conclusion,
If I can not catch something more official from OutSystems and we have thousands of developers starting each day, Leandro Fernandes' idea can be a valid one, but in my view we have the risk to put people's development (creating flows) to the right.
How do you guys deal with a situation like this?
How can I give something from OutSystems that is like a dictionary, because if I say that is like this the other says that is like that, you know :)
Thanks to share your experience, I believe that this happened a lot!
Hello Nuno,
Like Leonardo mentions in his article, structuring your code like you'd structure a natural language is useful: it makes it more easily transmitted across readers (developers, in this case) because there's a common base of understanding. The direct conclusion is that a style guide, like a language, is a strictly cultural concept. This means that a style guide that makes sense to a group of people may not make a lot of sense to another group.
I suspect that "why to the right" is explained from a western perspective: most western languages are written left-to-right, so it stands to reason that you want your "happy path" to follow this direction. Contrast this with Arabic, Hebrew or Japanese where text is written right-to-left: I believe this style guide would be extremely unnatural to readers of those languages.
What I want to reach with this language analogy is one of Leonardo's first points - there's no such thing as a "correct" style guide: the people who you witnessed teaching these guidelines are simply propagating what makes sense to them. If you find that a specific style makes more sense in your environment, it makes sense to spread it across your team and implement it. What matters is that everyone working around you shares your viewpoint: a language is just a tool, and only as relevant as its speakers.
Hi Afonso,
Thanks for thinking and participating here.
I confess because we are so used to our small world that I googled to understand if it is another way to develop C# or other programming languages that we are used to work, depending of the part of the world that we are developing.
Does it make sense for someone not pressing an enter and continuing to write C# to the right?
I was in the level of one client, you brought this topic to global.
What you said makes all the sense, and yes, if we don't have defined roles anyone can define them. It is flexible! The poor developer (we), need to adapt to a new country, language, maybe business and the way that they define the flows because we don't have a global standard.
Now I'm curious, I will ask someone in Dubai how they make the flows.
Personally I hate flows to the right, for a number of reasons. For one, eventually you'll have to go down again, with either a huuuge connector all the way from the right to the left, or go boustrophedon which I find unreadable (though in a large For Each you seldom can escape it).
Secondly, although many scripts flow left to right, code in general goes down. I don't know many high-code style guides that allow more than one statement on a single line. Since basically each node is a statement, going down makes much more sense to me then going right.
A third argument against going right is that I think the happy flow should move in a single direction, without too much meandering. You can't do that going to the right as, like I wrote above, you need to come back to the left.
As a fourth reason, consider that many unhappy flows end in an End or exception, meaning you'll have end nodes going down, which looks very odd indeed!
Hi all. This will always be a topic of debate, if only because different people have different tastes.
Obviously the styleguide I wrote is what makes sense to me, and it might be different to what makes sense to you. I don't have any problems with that, I'm not here to tell you what you should do, I'm here to tell you what I usually do, and you can cherry pick what you think is useful.
I could write objections to all your points above, but at the end they would be based on my experience, which might be different than yours.
I still stand by the principles, so whatever choice you make for your own styleguide, ask your team if the principles still hold:
@Leonardo Fernandes what you did was great and thanks a lot to share it!
That is not the point. I have worked for some years with this amazing platform, but not so many clients. It was the first time I was confronted with this situation and they presented me with your valid point of view. We have the link of your post in a client document. It is amazing.
Maybe we need another OutSystems MVP opinion to open the eyes to the community that this is an open topic.
You are an important and respectable member in the community (thanks for that) and because of that, people can assume that this is a role and an OutSystems consultant can go to a client and start changing because your point of view is the correct way.
The most important is consistency and roles inside a client. Now in the client we have 2 tastes already but that is our problem/challenge.
For now I will link this URL discussion in your post.
Thank you everyone for participating and thinking with us on this topic that generated a discussion in my team.
Hi all,
As one of Nuno's new colleagues, I would like to explain the reasoning why I was taught and prefer to set the True-branch of an If to the right.
I also agree that the happy-flow of an action should be coded from top to bottom. Generally speaking when placing an If, you assess whether you logic deviates from this happy-flow. If that is True, it makes sense that you would visually move away from the happy-flow by placing the branch to the right.
Think off exception handling like the validation of a form. You check per widget whether the user's input is inconsistent/incorrect/invalid or else. If that is the case, you move to the right, handle the exception and preferably provide feedback to the user and end the flow. Quick example. Regardless of Traditional or Reactive, I would code like such
Hi Dayne Oomes,What is the problem of the following approach to your flow, where the True branch is always going down?
The True branch of an IF should always go down. This should be the rule, as it brings many benefits.In the case of an exception to the rule where the True branch goes to the right (because the True IF condition would become, for example, negated or more difficult to implement and understand), then it should be created a comment to indicate that it is an exception.
--Tiago Bernardo
Hi Tiago,
There is no problem at all with the approach of all True-branches going down. I simply explained why I was taught and prefer to put the True branch to the right in response to Nuno's question about experiences and arguments for coding from left to right.
I would suggest there is no right or wrong in following mine or your approach if you stay consistent in either way to ensure readability of the flow.
I agree, though in the descriptions I would put a positive. E.g. "Description supplied?" instead of "Description <> """.
Totally agree, as long as you are consistent that is the most important.
Being consistently wrong or annoying isn't quite the right kind of consistent :D.