Best practices for Arcade expressions

While Arcade is a flexible and powerful expression language, there are some applications of Arcade that are better suited than others depending on the use case. Below are some of the recommended best practices for Arcade expressions in ArcGIS Velocity.

Best practices for Arcade expressions in Velocity

  • Expression complexity

    While Arcade allows you to write complex scripts, declare variables, and define and call functions, it is often advisable when building Arcade scripts in Velocity to keep them as simple as possible. Complex scripts tend to have more potential for errors but more importantly, they also will have more of an impact on analytic performance. Shorter scripts and expressions will be interpreted more quickly and therefore have a lower impact on processing speed.

  • Expression length

    Arcade supports lengthy multiline scripts, but just as with complex scripts, long scripts may also adversely impact processing speed. Therefore it is recommended to keep scripts as short as possible to avoid unnecessary performance hits.

  • Avoiding loops

    Often when writing scripts and programs it is useful to leverage looping routines that iterate over a set of data and repeat a procedure or test for certain conditions. Although this is supported in Velocity it can reduce performance of your analytics, sometimes dramatically. For this reason looping logic should be used infrequently and judiciously in your analytic expressions.

    In most cases in programming and scripting, infinite loops can present a challenge. With Velocity they can be particularly problematic, so care should be taken to avoid conditions in your expressions that could lead to infinite looping when your analytic is running. If this happens you will likely observe a significant impact to your analytic's performance.

    When Velocity validates an analytic and determines that it may contain looping logic it will return a validation warning. This will not prevent you from running the analytic but serves as a reminder that loops can have a negative impact on performance.

  • Testing an expression with sample values

    In some cases testing with sample values is necessary in order to produce the correct data type from the configured inputs.

    For example, if you have a string field called BaseDateTime containing date values in ISO 8601 format like 2019-04-05T12:05:18.095Z and wish to parse the strings into dates, you might use an expression such as Date($feature.BaseDateTime). The Arcade expression builder will attempt to validate the expression by the evaluating it against a sample string. The default sample string, however, is Pacific, which will not successfully parse to a date. Once the expression builder is dismissed, a validation error will appear indicating that you must configure a valid expression that returns data in the target field type.

    Arcade editor testing expression with default value

    You can bypass this behavior by passing in your own valid sample string in the expression builder. To do so, reopen the expression builder and in the Globals list, click the pencil icon next to the string field containing the date information.

    Arcade editor editing the sample value

    Paste in an example string in the same date format as the values in the field. When you next test the expression, a valid date value will be generated, and the expression can be used in the tool successfully.

    Arcade editor testing expression with sample value