Outsystems Code Documentation


I am on Development environment on cloud.

I am on a mobile project team using OutSystems, but once I move out the project and new versions of the mobile application comes, how will the next support developer understand the low code platform? I know we can use comments. 

What are alternate ways for documentation, what is the best practice for documenting low-code in OutSystems?

Maybe OutDoc helps with what you want.


We have a very large number of projects that will need to be supported over at least a 10 year period so we face exactly the same issues. Here is how we approached the problem.

We documented a set of internal standards, for example

* eSpace names. All espaces were named based on the type of content and complying with the 4 layer archetecture. For example XXXXXX_ENT for entity data, XXXXXX_CR for Core and business logic, XXXXXX_USR for screen and user logic etc. This way you know where to look for what type of code and can help control circular and cross reference violations, espaces that are shared across projects had an additional "S" to show they are used outside (ie XXXXXX_SCR for a shared core)

* All entities must have a description entered, most attributes inside entities should have a description

* All entity espaces must have at least one entity diagram, on complex structures there should be an entity diagram explaining each entity linking concept

* All shared actions must have a description

* All webblocks must have a description

* All user roles must have a description explaining what they are used for

* Don't mix espace uses, ie don't put entities inside a _USR espace even if you think it won't be used else-ware

Then as Jogait said use the OutDoc utility, it will show you the descriptions agains everything. We use this at least once a month on all ongoing projects to do a code review and ensure developers are following the standards.

The most important thing is not so much the exact rules but the consistency of following the rules. Document them and ensure the they are always followed, that way when a new developer looks at a project they know where to look and what to look for.