Skip to content

Script Development / Code Arrangement and Organization

Script Sets, Scripts, and functions should be organized according to a certain logic, rather than piling code together at random. Reasonable arrangement of Script Sets and Scripts is beneficial for code maintenance and system runtime efficiency.

1. Reasonably Divide Script Sets and Scripts by Purpose and Type

In general, the following code organization approaches are recommended:

  • Create separate Script Sets for business processing Scripts by industry, project, organization, and other criteria, such as: eShop, IoT, monitor, sales, marketing, etc.
  • When there is too much code, divide low-frequency Scripts and high-frequency Scripts according to usage frequency, such as prediction, advanced_prediction

2. Calling Functions in Another Script

Scripts can be divided into different Scripts or Script Sets according to different needs such as functionality and purpose, and code located in different Scripts can call each other. When you need to call a function in another Script, you only need to import the corresponding Script.

When importing another Script, you must use the fixed syntax:

Python
1
2
3
4
5
6
# import <Script Set ID>__<Script ID>
import demo__script

# or use an alias to shorten the length
# import <Script Set ID>__<Script ID> as alias
import demo__script as script

In the Script editor, you can point the mouse at the question mark icon in the left sidebar to directly copy the relevant statement

If you need to export a Script Set, the other Scripts that this Script Set depends on also need to be exported together. Otherwise, the exported Script Set will actually be unable to run because functions are missing!

Scripts or Script Sets are not Python modules and cannot be imported with import in the first place

However, DataFlux Func implements a dynamic loading mechanism internally and allows the use of import statements to load dynamic code. Therefore, the following forms are all incorrect.

Python
1
2
3
4
5
6
# Incorrect form 1: import a Script Set as a module
import demo

# Incorrect form 2: import a Script as a module
import demo.script
from demo import script

In addition, when importing Scripts, you should be careful to avoid circular references, such as:

Python
1
2
3
4
5
6
7
8
# Script script2 under the Script Set demo
import demo__script2

# Script script3 under the Script Set demo
import demo__script3

# Script script1 under the Script Set demo
import demo__script1

Note: when editing multiple Scripts at the same time, if another Script is currently imported, the referenced Script will actually execute using the published version, and the system will never import the draft version at any time!

3. Code Volume and Dependency Chains of a Single Script

When DataFlux Func runs a Script, it dynamically loads the Scripts needed for execution. If one of the Scripts imports another Script, the imported Script will also be dynamically loaded.

Therefore, if certain functions in a Script are called especially frequently, you can consider extracting them into a separate independent Script to reduce loading overhead. It is recommended to keep a single Script within 1000 lines.

In addition, you should also avoid excessively long dependency chains that cause unnecessary performance loss. For example:

  • Script 1 depends on Script 2
  • Script 2 depends on Script 3
  • Script 3 depends on Script 4
  • Script 4 depends on Script 5
  • ...

Python built-in modules and third-party modules are not subject to this restriction

4. Cases Where Scripts Are Not Divided

Although the above mentions reasonable planning of Scripts and the methods of calling between Scripts, in certain specific cases (such as when the common functions actually used are few and simple), you can consider not dividing Scripts and putting all code in the same Script.

This approach, although it introduces a little code redundancy, also brings some additional benefits:

  • A single Script can run, reducing loading overhead
  • It will not be affected by changes to common functions
  • No need to consider dependency relationships when exporting Scripts

Please choose the most reasonable way to plan Scripts according to the actual situation

5. Shorthand for Cross-References Between Scripts in the Same Script Set

Added in version 1.1.0rc51

Under the same Script Set, references between Scripts can omit the Script Set ID part (i.e., write only the part starting with __).

This is convenient when a Script Set is cloned: after the Script Set ID changes, internal functions can still reference each other correctly.

For example:

Python
1
2
3
4
# Script: demo__utils

def echo(msg):
    return msg
Python
1
2
3
4
5
6
7
# Script: demo__test

# Equivalent to import demo__utils as utils
import __utils as utils

def my_func(msg):
    return utils.echo(msg)

6. Avoid Over-Encapsulation

Python is a multi-paradigm programming language. You can use simple procedural programming, and you can also program in an object-oriented way.

However, in DataFlux Func, to facilitate debugging, it is recommended to write code using a more procedural programming style to avoid over-encapsulation.

For example, the same functionality can be implemented in 2 different ways:

Python
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
import requests

# Procedural
def query_some_api(url, params):
    r = requests.get(url, params)
    return r.json()

# Object-oriented
class APIQuery(object):
    def __init__(self, url):
        self.url = url

    def do(self, params):
        r = requests.get(self.url, params)
        return r.json()

def test_api_query(url, params):
    api_query = APIQuery(url)
    api_query.do(params)

In the above example, although both can achieve the same functionality, since query_some_api(...) is a function that can be called directly, in the editor, you can select this function and directly fill in the parameters to run it.

However, if you want to debug and run the do(...) method of the APIQuery class, you must instantiate the object before calling it, so you can only write an additional test function test_api_query(...) to call it.

Please choose the specific approach based on the actual situation as appropriate.