Low Code Development Best Practices

Iotellect allows developers to create powerful and feature-rich solutions on its low code platform, reducing the complexity of development by minimizing or eliminating the need for manual coding and scripting. However, even on a low code platform, there are best practices to follow to ensure the quality and scalability of applications. These article lists a few common best practices for low code development, including naming conventions, coding practices, and documentation guidelines. By following these best practices, developers can create high-quality applications that are efficient, scalable, and easy to maintain.

Here are some general practices that can help improve work processes, avoid common mistakes, and achieve better results. These tips cover a wide range of topics that can help keep your projects maintainable.

• Choose a single language to be used for all non-client facing text, such as names of properties, functions, variables and so on.

• Be vigilant and systematic in avoiding typos and proofreading all text.

• Backup your work regularly.

• Create events for main and important actions.

• Fill in the "description" and "comments" fields, and avoid using caps lock or demanding language.

• Use Java instead of expressions when necessary, but remember that scripts can create system vulnerability, so think about permissions.

• Avoid using periodical bindings in favor of event-driven ones, use periodic triggering only in extraordinary situations.

• When working with dashboards, write bindings in a logical order.

• When working with dashboards, try not to activate heavy bindings on hidden areas in the background every time. Make activator on Shown event for these cases.

• When working with dashboards, always use custom properties as transit points between data from back-end and front-end.

• Regularly refer to the knowledge base and documentation.

• Using the "sleep" function is a bad practice that in almost all cases leads to unreliable behavior. Try to avoid it in all cases. Bind your logic to events and conditions instead.

• Make reports fully parameterized.

Consistent naming conventions, both stylistically and conceptually, are fundamental to maintainable projects.

• Use camelСase naming for contexts, context entities, data table fields, and other “unique ID” names. If a name contains an abbreviation, capitalize only the first letter of the abbreviation and use lowercase for the rest of the word.

• Make use of description and comment fields to communicate the purpose of a given property.

• Avoid using trademarks and personalized names directly, refer their “master” definitions instead. This will greatly help refactoring your app in case of any branding and corporate identity changes.

• Give your contexts, variables, and functions understandable and sensible names.

• Use a unified object naming scheme for application testing and debugging

• Use appropriate verbs to name functions and rule sets.

Several key steps to take at the beginning of a project, including creating a project map, anticipating localization and scalability, and organizing the project into meaningful groups.

• At the beginning of a project, create a top level project map.

• When designing an app and its development methodology, only consider the product requirements. Do not add any additional features.

• Consider the potential need to make the project available in different languages or adapt it to different regions or cultures.

• Design the product in a way that allows it to expand or accommodate larger volumes of data or users as necessary, i.e. scaling.

• Group sets of the product resources according to their meaning.

• Remove unnecessary resources.

• Avoid creating redundant contexts.

• Consider permissions, users, and roles.

• Create individual accounts with admin permissions if you are not using LDAP in your project/product.

When writing code, following certain best practices can help ensure that your code is efficient, readable, and free of errors.

• Avoid putting links, passwords, usernames, or other strings in expressions. Instead, use variables.

• Do not leave commented-out blocks of code in expressions, queries, or scripts. If you need to test your expression, create a copy of a binding or function, fill it with test information, and delete it after successful testing.

• Avoid long expressions (more than 3-5 functions) and use rule sets instead.

• In expressions, when calling a function with a lot of parameters, put every parameter in a new line and start it with a comma. Add comments to each line whenever appropriate.

• Split long string constants into multiple lines.

As a technical writer, creating comprehensive and clear documentation is crucial for ensuring that users can understand the features and capabilities of the product or service they are using, and that other engineers can understand how the product should work. Here are some best practices for writing technical documentation:

• Always write documentation for each created block of functionality.

• Mention only key information in the documentation.

• Use a reliable documentation platform.

• Use templates for consistency in formatting and organization.

• Write documentation for every context as it’s completed.

• Emphasize important information for the end user.

Was this page helpful?

Tell us more

Send

Thank you!