Code Analysis Patterns, Their Impact and How to Solve Them

Code analysis patterns refer to several coding patterns that have been analysed over time. These are often used by developers without the knowledge of certain consequences they might create on applications. Such implications can range from poor performance of the application to the poor abstraction of services and other database vulnerabilities.

This blog will focus on a few code patterns, their impact on applications, and the best way to resolve these issues.

‍

1. The appropriate way to count records

When we use the Count property to get the number of records returned in an aggregate or an SQL query, the MaxRecords property is always overridden the first time. In other words, the compiler creates two queries: one to retrieve the desired output and one to count the number of records. The query structure used when retrieving information from SQL queries should be adapted to now count the records as shown in Figure 1.

To check if the query has retrieved any data always use the <Query>.List.Empty property instead of <Query>.Count = 0

‍

‍

‍

2. Avoid using inline JavaScript

Extended properties in service studio allows developers to define custom CSS styles inline on screens and WebBlocks. This is often done to adjust padding or to style a particular element on the screen. This results in CSS code duplication on several screens as developers customise the screens. When a particular style needs to be changed on several pages, customising them in this way can have significant effects over time. Furthermore, this increases the technical debt on the architecture dashboard.

Stylesheets should be created along with custom themes that are relevant to the application being developed. These should be stored in a central place where styles can be retrieved from the theme. This approach is the best practice because when a change to the theme is requested by the client, the changes are done on the central theme. Changes are then executed on the entire application or affected screens.

‍

3. Avoid the use of large session variables

Session variables are used to store small amounts of data during a user’s active session. When making a data request, the session is then loaded with the requested data. To avoid performance issues and CPU utilisation issues, it is recommended to store small amounts of data in session variables. These occur when large chunks of data are requested and stored in a session variable. Large chunks of data can be stored in a cache. Cache aside or on-demand caching is a strategy that is used for retrieving data from the cache.

When there’s a “miss” (the cache doesn’t have the data), the application is responsible for storing the data in the cache so that it will be available the next time. The next time the application tries to get the same data, it will find what it’s looking for in the cache. In order to prevent fetching cached data that has changed in the database, the application invalidates the cached data while making changes to the data store, using specific logic in an Action as shown below.

‍

‍

‍

4. Updating site properties should be avoided

Site properties are defined as global variables that have constant values which do not change. Site properties, loaded by the server and then cached for faster access, are used to hold data that must be available across the module. Site properties can be updated manually in Service Center. The site properties can also be updated programmatically, but it’s not recommended, as site properties aren’t designed to be a “global variable” and store information that changes frequently.

Place non-configuration information that needs to be changed in a specific database table. This way the data can be updated without invalidating the cache and without degrading the performance of the application.

‍

5. Optimising data preparation

To allow a pleasant user experience, it is important to ensure that data retrieved in the preparation is only fetched once and any necessary calculations are done upfront to avoid calling the server countless times. Where queries are complex, it is better to use SQL queries to retrieve data rather than using aggregates with loops. The server becomes overloaded by preparations that take a long time to run because of fetching tonnes of data.  

To overcome this dilemma, it is recommended to understand your database model and the information contained therein so that you fetch the information required to load the screen using one call. It is also crucial to understand SQL joins so that they are used correctly to fetch the required data at once.

‍

6. The sizes of images should be controlled

Design experts have a primary goal of producing high-definition images for use. However, in most cases, images have higher pixels and developers often tend to resize the images to fit the area they want them displayed. This is not a good practice because screens are affected when large images are loaded, worse on mobile applications with sliders on home pages.

This slows down the application and the amount of time required for the images to load is increased. Images may be specifically designed for mobile or web use, however, developers tend to use the same images in various parts of the application including thumbnails. The images should always be compressed and tailored to fit the display area, and the images used for thumbnails should be separate from those used for full views. In addition, different images should always be used for different form factors.    

As the popular saying goes, “Rome was not built in one day” so does it take for one to be skilled in any profession. As you are now aware of some coding patterns, and perhaps some of them were part of your coding lifestyle, it is time to change.

I hope you enjoyed the blog! Sign up below to receive content that can help you to become a better developer not only in OutSystems but in many other programming languages.  

‍