Skip to main content

Code Analysis Patterns

OutSystems

Code Analysis Patterns

Up to date list of code patterns analyzed by current version of Trusted Advisor.

Check Release Notes to know when patterns have been included and/or changed.

Additional information on some patterns can be found in Best Practices.

Architecture

  1. Lack of module classification

    Module not placed in one of the Canvas layers in Discovery

    Impact

    A module not classified (undefined) in Discovery, does not allow to properly validate the architecture for canvas violation patterns.

    How to Fix

    On the Discovery application, check the unclassified module. Classify its layer based on its nature and on architecture best practices (Orchestration, End-user, Core or Foundation). In case a module falls on more than one layer classify it as the top one. E.g. if a module has concepts of End-user layer (screens) and the Core layer (entities), the module should be set as End-user.

  2. Orchestration application providing services

    Orchestration application providing services

    Impact

    An Orchestration application must be fully isolated, not providing services - any reference to it normally reveals the existence of misplaced reusable code. Furthermore, being in the top layer, any reference to an Orchestration application may inherit the entire hierarchy of modules beneath it.

    How to Fix

    Check Discovery for which modules are being consumed and move them to Core/Library applications, according to the concepts.

  3. Orchestration module providing services

    Orchestration module providing services

    Impact

    An Orchestration module is not supposed to provide services - any reference to it normally reveals the existence of misplaced reusable code. Furthermore, being in the top layer, any reference to an Orchestration module will inherit the entire hierarchy of modules beneath it.

    How to Fix

    Check Discovery for which elements are being consumed. Extract those elements and move them to Core/Library modules, according to the concepts. Check the forge component Refactor for more support on this operation.

  4. End-user application providing services

    End-user application providing services to non-Orchestration applications

    Impact

    An End-user application is not supposed to provide reusable modules to other applications. References to an End-user compromises the life cycle independence between applications and typically pulls a lot of indirect unwanted references.

    How to Fix

    Check Discovery for which modules are being consumed and move them to Core/Library applications, according to the concepts. Check the Forge component Refactor for more support on this operation.

  5. End-user module providing services

    End-user module providing services to non-Orchestration modules

    Impact

    An End-user module is not supposed to provide services - any reference to it normally reveals the existence of misplaced reusable code. References to an End-user compromise life cycle independence between applications and typically pull a lot of indirect unwanted references.

    How to Fix

    Check Discovery for which elements are being consumed. Extract those elements and move them to Core/Library modules, according to the concepts. Check the forge component Refactor for more support on this operation.

  6. Core application consumed by Libraries

    Core application with modules consumed by Library applications

    Impact

    Library applications are not expected to consume modules from a Core application since they should not rely on business-related services.

    How to Fix

    Check Discovery for consumed modules. If they are Libraries, they should be moved to a Library application. If they are Core modules, you need to question if the logic in the Library modules that is consuming those modules is not misplaced.

  7. Core module consumed by Libraries

    Core module providing services to Library modules

    Impact

    Library modules are not supposed to consume services from a core module. They need to be fully isolated with no business logic or reference to a business module, otherwise consuming a library might bring unexpected impacts.

    How to Fix

    Check Discovery for consumed elements. Either they should be moved to a library module if they don't have a business nature, or you need to question if the logic in the library modules that are consuming the core elements is not misplaced.

  8. Core module providing services to sublayers

    Core Module in a higher sublayer providing services to core modules in lower sublayers

    Impact

    This violation indicates that within the core sublayer of modules there are upper layer modules (like BL, API or Sync modules) that are being consumed by lower layered ones (example CS). This can indicate a wrong abstraction of concepts, where some core concept is becoming dependent on certain business concept composition. These types of dependencies inside core modules should be normally done from top to bottom also.

    How to Fix

    Validate the violation on Discovery. In this case you should move the upper core module to a lower sublayer (because it is supposed to provide services to other consumers bellow) or If not, you should check if any of the consumed object/logic from the upper module is not misplaced, requiring it to be refactored to the lower sublayer module.

  9. Foundation module providing services to sublayers

    Foundation module in a higher sublayer providing services to Foundation modules in lower sublayers

    Impact

    This dependency reveals a wrong abstraction of concepts that can generate unmanageable dependencies. The module in the higher layer is supposed to be a composition of lower modules and not the other way around.

    How to Fix

    Check Discovery for the consumed module. Either move it to a lower sublayer because it is supposed to provide services to its current consumers. If not, you need to question if the consumed objects in the higher module are not misplaced, requiring to be moved to a lower sublayer module.

  10. Cyclic references between applications

    Cyclic references between two Library or two Core applications

    Impact

    Cycles between Core or Library applications usually means wrong isolation of reusable modules that leads to consumers being unnecessarily impacted when requiring only one of the applications.

    How to Fix

    Understand the conceptual relation between applications involved in a cycle, to decide which application is not supposed to be consumed by the other. Check Discovery for the wrongly consumed modules and decide whether moving them to the application that is supposed to be consumed makes sense in terms of conceptual abstraction.

  11. Cyclic references between modules

    Cyclic references between two Library or two Core modules

    Impact

    Cycles between modules usually means wrong service abstraction and bring unwanted impacts in both development and runtime.

    How to Fix

    Understand the conceptual relation between modules involved in a cycle, to decide which module is not supposed to consume the other. Check Discovery for the wrongly consumed elements and decide whether moving them to the module that is supposed to be consumed makes sense in terms of conceptual abstraction, or if there is a need to move them to a composition module on top of the two.

  12. Client and Server side entities not isolated (Mobile only)

    Both client and server-side entities and logic implemented in the same module

    Impact

    Supplying client-side logic and entities together with reusable server-side definitions does not promote the optimized design of mobile functionality. While server-side logic can be extended to support several applications, generalizing client-side logic for the same purpose tends to generate redundant information and useless sync logic for each specific mobile App.

    How to Fix

    Client-side logic should be catered to the use cases of each mobile application. The normal pattern is to have a generic server-side module around a concept, e.g. Accounts, and a specialization for each mobile app that handles Accounts. For instance, if you have a Mobile Banking (MB) application for end-users and a Mobile Agent (MA) application for agents, on top of the server-side core service Account_CS module, you should create the MB_Account_CS and the MA_Account_CS modules with the specialized client-side DB and logic for each mobile app.

  13. Public entities not read-only

    Public entities should be exposed as read-only

    Impact

    When public entities are not exposed as read-only, their respective entity actions for creating, updating and deleting records are available to be referenced by any consumer. These entity actions directly affect records in the entity, allowing any consumer to perform inconsistent and potentially destructive changes without considering the complete semantic and validation of the operation.

    How to Fix

    Enable "Expose Read Only" in public entities and create your own public actions for creating, updating and deleting records of those entities, abstracting all validations, business rules or other side effects such as audit trailing or notifying changes to another system.

  14. Library or Core module with screens

    Misplaced end-user screens

    Impact

    End-user screens that support business processes should only be provided at Orchestration or End-user modules. The only exceptions are exception handling screens or reusable pop-up screens.

    How to Fix

    Move end-user screens supporting business processes to end-user modules. If you are building test screens to validate your logic, remember to delete them when obsolete. If you want to keep the test for future reference, then move the screen to a test end-user module. This way, you can temporarily perform quick tests directly on the eSpace that you are developing. If you are building reusable pop-up screens, suffix them with "popup" and they will be ignored.

  15. Monolithic Web UI Module (Web only)

    Module has too many end-user interfaces

    Impact

    A monolithic End-user or Orchestration module with too many screens probably contains too many business processes inside with independent lifecycles. The module becomes very heavy and hard to maintain, and the lack of granularity causes unwanted impacts on maintainability and release management.

    How to Fix

    Identify the independent UI flows, with no destinations among themselves, and separate them in multiple modules.

  16. Monolithic mobile UI module (Mobile only)

    All mobile UI content is being kept in the same module

    Impact

    Due to technical requirements of the Native Build generation, all screens of a mobile application, including the exception flow and the menu, must be placed in the same eSpace. Hence, the UI screens module can become a monolithic eSpace that keeps growing. This will make different life cycles for different processes hard to maintain.

    How to Fix

    Keep module with all the Screen Flows, but keep screens only as layout containers. Supply UI content in web blocks from different Core widgets modules, organised per functional area to allow different life cycles per such functional area.

Performance

  1. Unlimited records in aggregate

    Number of records fetched from DB is not set in aggregate

    Impact

    More records are fetched from the database than are used by the application, resulting in useless I/O and memory consumption.

    How to Fix

    Set the Max. Records parameter of the aggregate to the required usage.

  2. Unlimited records in SQL query

    Number of records fetched from DB is not set in SQL query

    Impact

    More records are fetched from the database than are used by the application, resulting in useless I/O and memory consumption.

    How to Fix

    Use ROWNUM (for Oracle) or TOP (for MS SQL Server) in the SQL query to limit the number of records according to required usage. Be aware that in SQL queries the Max. Records parameter only limits the number of records displayed, not the number of records fetched from the database.

  3. Query data in Viewstate (Web only)

    Screen actions are using query data obtained in preparation

    Impact

    Page size affects usability since it will increase the time to submit a form. If you use screen preparation data on-screen action, that data will be saved in the page's viewstate. Since the viewstate is a part of the page, it is sent to the client with every requested page. The viewstate is also sent back to the server on a post, postback and AJAX request.

    How to Fix

    Avoid using data from screen preparation in screen actions. For instance, instead of using the TableRecords record data, send the Id of the row as a parameter of the screen action and fetch the data from the database again as needed. If you need the full list of records, simply refresh the query - it is better to rerun the query server-side than to send the data back and forth through the viewstate.

  4. Large variable in Viewstate (Web only)

    Screen local variable with large type is being used in a screen action

    Impact

    When local variables defined at screen level are used in screen actions, their data is saved on the screen viewstate. Viewstate is included in the response of all requests made to the screen (both first load and AJAX requests). Additional data in viewstate, especially with large data types, increases response size and loading time in the browser.

    How to Fix

    Avoid using screen local variables in screen actions.

  5. Timeout in Server Calls (Mobile only)

    Long timeout in server action call

    Impact

    Default timeout for server action calls is too long or an explicit timeout in a server call is too long (more than 10 seconds). In a mobile application, a server call should be efficient. 10 seconds is all it takes for a device to go to sleep mode or lose network.

    How to Fix

    Prepare and cache data in advance in the server-side to be promptly available when required. The timeout should also be reduced to fail quickly (with a "retry later" message), except on explicit operations, because it's acceptable for those to take a little bit longer.

  6. Inline JavaScript

    Inline javascript defined in an unescaped expression

    Impact

    Javascript defined at the screen/web block level is optimized by OutSystems. For example, if you have the same web block in your screen twice, it’s only included once. It also improves maintenance.

    How to Fix

    Define JavaScript at the screen/web block level instead of in inline expressions.

  7. Inline CSS style

    CSS style is being defined as an extended property of a screen element

    Impact

    CSS and HTML should be kept separated. Inline styles are inefficient, harder to maintain and make your HTML bigger.

    How to Fix

    CSS should be centrally managed in the application style guide to avoid loading a proliferation of CSS files. If the CSS is too specific for one screen or one web block, define your CSS at the screen/web block level instead of doing it in extended properties.

  8. Dynamic inline parameter

    Dynamic expression used in an expanded inline parameter of a SQL Query

    Impact

    Inline parameters that change too often don't allow the database to optimize execution plans since it keeps generating different queries.

    How to Fix

    Change the query to remove the frequently changing inline parameters. Consider selecting specialized queries depending on the parameter or using sub-queries or temporary tables.

  9. Site property update

    Site property being updated in the application logic

    Impact

    When a site property is updated it invalidates the cache of the eSpace. This causes subsequent accesses to cached data to have to be fetched from database or recalculated in the application logic, which may result in a performance hit.

    How to Fix

    Avoid changing site property values programmatically by using alternatives such as storing the value in the database.

  10. Inefficient empty list test

    Using the Count property of an aggregate or SQL query to check if results were returned

    Impact

    For performance purposes, OutSystems query optimizer assures that output of aggregates and advanced queries return only necessary data to feed screen. So, Count property needs to execute an additional query to get the total number of registries.

    How to Fix

    Use List.Empty property to test for lack of results instead of List.Count.

  11. Inefficient query count

    Counting query results using an inefficient query

    Impact

    SQL queries are usually designed for retrieving data and may perform joins and fetch extra data, needed for processing but that are not required to count the query results. When using the Count property of a query, the same query is executed to count the results, which is inefficient since it will use the same query definition.

    How to Fix

    Use a simplified SQL query just to count the results in a more efficient way, removing unneeded extra data and joins.

  12. Inadequate data preparation

    Query is being executed inside a loop

    Impact

    Each run of the query may be fast enough, but when inside a loop, the total amount of DB effort may be considerable.

    How to Fix

    Often executing only one complex query to obtain the required information is better than executing a simple aggregate in a for-each loop. Also check if the entity model copes with your needs - when the database model is inadequate, getting the required information proves to be too complex to be fetched by a single query.

  13. Large session variable

    Session variable with large or complex data type

    Impact

    On all screen requests, the current session's data is loaded from the database. This data is a binary including all session variables content. If large or complex variables are used, each request will take longer to process the session data (include serializing and deserializing it) increasing response times and causing contention in all concurrent requests.

    How to Fix

    Store this data in your own entities using the session identifier as primary key and fetch it only when needed. Keep the session limited to context information that is useful in every request.

  14. Large image

    Large images included in module

    Impact

    Large images have different kinds of impact in an application. When large images are being used in a screen to be displayed they will need to be fetched from the server, increasing bandwidth usage and request processing time in the browser. Even setting their width/height set to lower values, this will not reduce the bandwidth fetch of the image from the server. On the development side, a module with large images takes more time to be saved and published, consuming additional bandwidth when being uploaded or downloaded from the server.

    How to Fix

    Reduce the size of images to the minimum needed to be correctly displayed to the user (below 150KB/500KB for Mobile/Web Applications). Reduce the image's resolution to a maximum of 1024px. Consider the possibility of having big images as external resources not contained inside the module itself.

  15. Large resource

    Large resources included in module

    Impact

    Having large resources in the module can really impact the publishing and downloading when publishing to the environment. This will slow down the development team and also the publishing of those modules in the environment.

    How to Fix

    Reduce the size of the resources to the minimum needed for its usage (below 150KB/500KB for Mobile/Web Applications). Consider the possibility of having the resources served externally to the application. E.g. having a screen to upload the resource and have it then stored in the file system or in a Binary DB table.

  16. Avoid Server Calls (Mobile only)

    Server actions being called in client events

    Impact

    Server calls should be avoided on client events (On Initialize, On Ready, On Render, On After Fetch). These events are serialized in the request and server calls may tremendously impact the wait time to render the screen.

    How to Fix

    A mobile app should rely on local storage for performance and offline. Server-side calls should be limited to synchronization calls (typically performed on business events fired in screen actions, session start or online events) and online transactions (typically performed in screen actions).

  17. Non-Optimized Local Data Fetch (Mobile only)

    Local data fetch performed in client events

    Impact

    Local data fetch should be avoided on client events (On Initialize, On Ready, On Render). These events are fully serialized, not taking advantage of the parallel fetch of data while the screen is being already rendered.

    How to Fix

    Retrieving data should occur inside data fetch calls to enable the parallelization of several data fetches and the screen render. If a data fetch depends on a previous fetch, use the On After Fetch event.

  18. Non-Optimized Local Storage (Mobile Only)

    Local storage model is not optimized

    Impact

    Local storage is being either copied exactly from server entities or still using a complex model (including too many fields, foreign keys, complex data types). This forces the use of multiples joins in Client Aggregates, which hinders the performance of the application in mobile devices.

    How to Fix

    Simplify local entities to the minimum number of attributes and de-normalize them as much as possible, still keeping them simple. Review client aggregates for unnecessary joins.

  19. Not taking advantage of Local Storage (Mobile Only)

    Too many server calls (screen data action) instead of using local storage

    Impact

    Using too many screen data actions that gather data from server is an indication that local storage is not properly defined or being used, as all data is being retrieved from the server. This hinders performance and offline requirements in mobile applications.

    How to Fix

    Implement proper synchronization mechanisms and local storage to make sure that most data is available in the local storage, which also facilitates offline scenarios.

  20. Multiple Server Calls (Aggregates or actions) inside Client Actions (Mobile Only)

    Multiple Server Aggregates or Server actions calls inside Client Actions

    Impact

    Each server call or server aggregate is a different request, generating its own overhead on establishing the connection and launching a server-side process. Multiple processes also generate different database transactions.

    How to Fix

    Instead of sequencing a set of server calls or server aggregates on your client-side code, compose all required server logic in a single server action to reduce the number of server calls.

  21. No Offline sync method (Mobile Only)

    Offline Sync framework not used correctly

    Impact

    No offline sync is being made or is being executed with poor performance.

    How to Fix

    Place the local entity sync actions inside the OfflineDataSync action, configure manual and automatic start of sync and use TrigerOfflineDataSync for background synchronizations. SyncUnit parameter should be used to prevent updating unnecessary entities.

  22. No asynchronous offline sync (Mobile Only)

    Server data is not being stored in the local database asynchronously

    Impact

    Storing server data synchronously will result in blocking screens and/or actions that may impact the overall user experience.

    How to Fix

    Use TriggerOfflineDataSync to execute OfflineDataSync asynchronously and react to the OnSyncComplete event to update ui modules.

  23. CSS in the screens style sheet (Mobile Only)

    CSS in the screens stylesheet

    Impact

    Having CSS spread through different screens normally bring future maintenance issues. Having the CSS centralized in the theme helps with future changes. Also having CSS defined on the mobile screens will create flicker when navigating through different pages.

    How to Fix

    Define the class inside the theme of the application. Even if it's only a small change it is better to define a specific class (that can then be reused) for it than add to a specific page and then copy the same class over and over.

  24. Set the Width of Image Widgets (Mobile Only)

    Image Widgets without width

    Impact

    If you do not set the width and height of an Image widget, the user can get a flickering effect while the final image is being downloaded. For example, not setting the image height might cause the total height of the screen to change until the image loads completely since the widget height will be changing from 0px to the height of the final image.

    How to Fix

    Set the width and height of the Image widget to the expected size of the final image. If you only set one of them the other will be adjusted proportionally.

  25. Avoid Long-Running Timers

    Avoid running Timers and Jobs longer than 30 minutes.

    Impact

    Having a timer that exceeds the platform's timer timeout threshold may result in reprocessing of the same code and data because the automatic retry mechanism for timers of the platform reruns the code in case of errors. Following the wake timer pattern will decrease the probability of the timer being interrupted by the scheduler process, because it reached the platform's timer timeout threshold. Using the wake timer pattern can (1) reduce the probability of a timer being interrupted. (2) Avoid cases of data inconsistency. (3) Avoid endless reprocessing of the same data.

    How to Fix

    Long execution timers should follow the wake timer pattern to reschedule themselves to restart and continue the current task at hand. This is accomplished by adding an explicit logical timeout inside the timer logic that when reached takes the necessary actions to properly terminate the current execution, store the current progress of the process in such a way that when its execution restarts it can easily pick up the execution from this stored last point. This pattern ends with a wake timer action for itself at the end of the timer flow. Another good practice for long-timers and batch jobs is to define them with checkpoints so that the timer can be killed and restarted with no impact on the data. At these checkpoints, consider executing partial commits to ensure that if some error occurs the processed data is only rolled back until the last commit (and avoid processing the same data all over again on next execution).

  26. Keep the Splash Screen Simple and Fast (Mobile Only)

    Complex Splash Screen

    Impact

    Adding heavy or lengthy operations to the splash screen will increase the time that the users must wait to use the app. Additionally, if the splash screen has a complex UI, the users may see a blank screen before the splash screen renders.

    How to Fix

    To keep the splash screen simple and fast to load you should avoid:

  • Requests to the server
  • Heavy logic
  • Complex UI, namely too many Blocks

Security

  1. Disabled button

    Disabled actionable button, that is still visible

    Impact

    The disabled property doesn't prevent an experienced person from enabling the button by using, for example, the development tools on a browser. This will lead to the ability to enable the functionality and allow the user to press the button even if he didn't have permission or was unable to press it.

    How to Fix

    In the button, instead of having the Enable property to false, use the Visible option as false instead (or in conjunction with the other one). This will prevent the rendering of the button completely on the client browser and will prevent the possibility of an experienced user to hack the button and enable the functionality.

  2. Injection

    Unescape/unencoded user inputs or screen variables

    Impact

    Screen user inputs and variables may be used for HTML or Javascript injection. This vulnerability may also be exploited in Cross-Site Scripting (XSS) attacks.

    How to Fix

    Enclose the screen user inputs and variables with the EncodeJavascript(), EncodeHTML() or SanitizeHtml() functions, depending on the situation, which will escape/encode characters in order to avoid injection attacks.

  3. SQL Injection

    Having screen input parameters that are directly used as expanded inline parameters in Advanced Queries, without being encoded or escaped.

    Impact

    The user input can include malicious SQL statements.

    How to Fix

    Enclose the input parameters with the EncodeSQL() function, which will escape and/or encode characters in order to avoid SQL injection attacks.

  4. Code Tampering

    Device is compromised, meaning it's rooted (Android) or jailbroken (iOS)

    Impact

    Mobile apps are susceptible to code modification. Even when encrypted by the operating system, sophisticated attackers can, and will, recover a decrypted binary, which gives them every opportunity to edit system calls, conditional statements, and other application logic.

    How to Fix

    To prevent an attacker from tampering your application, OWASP recommends you validate the integrity of your executable at runtime. With the Secure Device Plugin for OutSystems (available on Forge), developers may verify whether the user has compromised their devices to gain access to privileged subroutines and shut down the application in response. In order to use it Simply add a reference to the plugin and use the CheckSecureDevicePlugin action in the OnApplicationReady event. This ensures that the plugin will be included in the native build.

  5. Not Secure REST API

    Exposed REST services should enforce SSL/TLS and authentication

    Impact

    Unsecured connections may be read by unauthorized third-party and be target of Man-in-the-middle attacks.

    How to Fix

    Secure application end-points by configuring SSL/TLS, that ensures the data sent to the exposed service can't be eavesdropped or tampered with. OutSystems provides controls to exposed REST APIs with login/password protection, except when it’s configured for internal access only.

Maintainability

  1. Missing description on public element

    Required description on public elements

    Impact

    Meaningful descriptions in modules, public elements, entities and attributes make their purpose and expected behavior more clear. It’s crucial when consuming closed modules, as you cannot look at the implemented logic.

    How to Fix

    Add a description to the module, that explains the module's purpose and identifies which concepts it contains. Add meaningful descriptions to all of the module public elements, and their related parameters (or attributes in the case of Entities or Structures). If parameter/attribute names already follow well-established naming conventions, you can choose not to add a description (e.g. Id, Name, Label, Description, CreatedBy, UpdatedBy, CreatedOn, UpdatedOn).

  2. Unidentified public action managing transaction

    Public action not describing that it manages the DB transaction

    Impact

    Explicit CommitTransaction or AbortTransaction operations may affect your application as they may commit/rollback data in unexpected places. Since the content of public reusable actions may not be accessible, it is extremely important to explicitly describe when the transaction is being handled inside it, in order to avoid unwanted runtime behaviors.

    How to Fix

    Clearly identify in the description of the public action that the transaction is being managed and in which cases is being committed or aborted.

  3. Long undocumented flow

    Action with a long and undocumented flow

    Impact

    A preparation or screen action with more than 20 nodes or an action with more than 40 nodes is hard to maintain, mostly if it has no comments to explain the logic.

    How to Fix

    Break flow logic into smaller and potentially reusable actions and/or place comments to explain portions of your flow. Note: explore the 'extract to action' feature, available in the right-click menu when you select a portion of a flow.

  4. To many Legacy Code

    Module containing too many disabled code

    Impact

    Keeping a large amount of disabled code makes it cluttered and difficult to read. It increases maintenance cost and produces time waist, as people tend to interpret disabled code to understand if it is still relevant.

    How to Fix

    If the code has been disabled for a while or the app is in production with the correct behavior, simply remove it.

  5. Foreign Key must have Id Suffix

    Suffix foreign keys with "Id" (e.g. "CustomerId")

    Impact

    Suffixing columns with id will clearly identify them as foreign keys to other entities without the need to verify the properties of the field. Follow the same principle even on cases that don't do referential integrity, this will also show that the column references a value from another system/entity.

    How to Fix

    Add an Id at the end of field column names that reference foreign key entities. E.g. Instead of having a field that references the primary key (id) of the Invoice entity called Invoice it should be renamed to InvoiceId.

  6. Prefix Timer actions

    Timer actions should have the prefix “Timer_”

    Impact

    Identifying actions that are executed by timers using a naming convention, helps the team on what the action does without searching for their references. Also, this naming helps in not sharing these actions on other business logic.

    How to Fix

    Prefix the name of the actions used by the timer with the "Timer_" prefix. E.g. if the action used by a timer is called BootstrapCustomers rename it to Timer_BootstrapCustomers.

  7. Avoid hard-coded literals

    Avoid hard-coded literal values

    Impact

    The maintenance and natural application evolution are compromised each time a hard-coded literal is used. Since there is not an easy way to find a hard-coded literal spread into the logic, each time it needs to change, it severely increases the maintenance effort, the risk, and unpredictable behavior.

    How to Fix

    Keep these values in configurable entities, static entities or site properties.

 

Score Calculations

The final score in a report is a moderation of the scores of each category.

For a given category the score is calculated based on the weight of the patterns that have any finding versus all the patterns analyzed.

 

  • Was this article helpful?