Tips and tricks from a developer’s experience that you can apply to make your own Linx solution cleaner and easier to maintain and understand.
The amount of code in a complex application is enormous. Thousands of lines of code, hundreds of methods and classes means having meaningful and easy to interpret code is obligatory in big applications if you don’t want to get lost in the jungle. Even when applied to the emerging market of low-code tools, the rules of clean code still apply in one way or another.
With low-code tools, the abstraction layer removes the need to learn coding, design patterns and their associated best practices and pitfalls. But you can easily duplicate actions, create unmanageable processes and use ambiguous naming. Suddenly you notice the amount of bugs are increasing while the amount of new functionality is decreasing.
As an experienced C# developer, it is almost instinctual to apply the same coding practices, even when working in a low-code application such as Linx. If you are working in a large Linx solution and components don’t have meaningful names, or follow natural programming rules and best practices, life can get just a tad frustrating.
An example of a large, complex Linx solution
Let’s look at some of the common pitfalls and the best practices that we can apply to fix them.
1. The Name Game
Naming – the bane of a developer’s existence. As a developer, you spend more time reading code than actually writing code, so if methods, variables, etc. are poorly named, it can be even more time consuming to try and understand what is happening.
By applying good naming practices, it will become intuitive for you or for the next person that has to work on the solution, to identify and understand what is going on. You don’t always get it right on the first go, but as you go along, you can refine and improve. Naming can be difficult, but it is well worth the effort in the long run to keep your solution clean and readable.
Here are 3 practices that you can implement in your solution:
1. Meaningful Names
Give names that reveal intent. Questions that you can ask yourself are “What is it doing?” “What is its responsibility?” “What is its purpose?” The name should clearly tell you what something is doing or what something is for without ambiguity.
For example, consider the following process:
2. Pronouneceable Names
It’s easier for us as humans to understand when we can read names like a normal word or sentence and don’t need to make assumptions about what the name could be. This will also make searching easier.
For example, consider the following Custom Type called EmpRcrd vs the Custom Type called Employee
These 2 practices can be extended to your solution settings too. For example:
3. Pick one word for the same concept
When working in a large solution, you will likely have many instances where you are doing the same kind of thing, such as getting values or deleting something. You might choose words like get and delete, but someone else might use retrieve and remove. This will cause inconsistencies in the solution, and also make searching a little more difficult. Pick one word for the same concept and stick with it throughout