Skip to content

Script Development / Code Organization

Script sets, scripts, and functions should be organized according to a certain logic, rather than haphazardly stacking code together. Proper organization of script sets and scripts facilitates code maintenance and system operational efficiency.

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

Generally, the following code organization methods are recommended:

  • Create separate script sets for business processing scripts according to industry, project, organization, etc., such as: eShop, IoT, monitor, sales, marketing, etc.
  • When the code volume is excessive, divide scripts based on usage frequency into low-frequency and high-frequency scripts, such as prediction, advanced_prediction.

2. Calling Functions from Another Script

Scripts can be divided into different scripts or script sets based on functionality, purpose, and other requirements, and code located in different scripts can call each other. When needing to call a function from another script, simply import the corresponding script.

When importing another script, a fixed format must be used:

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 hover the mouse over the question mark icon in the left sidebar to directly copy the relevant statement.

If you need to export a script set, then other scripts that this script set depends on must also be exported together. Otherwise, the exported script set will actually be unable to run due to missing functions!

Scripts or script sets are not Python modules and originally cannot be imported using import.

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

Python
1
2
3
4
5
6
# Incorrect method 1: Importing a script set as a module
import demo

# Incorrect method 2: Importing a script as a module
import demo.script
from demo import script

Additionally, when importing scripts, care should be taken to avoid creating circular references, such as:

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

# Script script3 under script set demo
import demo__script3

# Script script1 under script set demo
import demo__script1

Note: When editing multiple scripts simultaneously, if the current script imports another script, the referenced script will actually be executed using its published version. The system will never import a draft version at any time!

3. Code Volume and Dependency Chain of a Single Script

Since DataFlux Func uses dynamic loading of required scripts when running a script. If one script imports another script, the imported script will also be dynamically loaded.

Therefore, if certain functions within a script are called particularly frequently, consider extracting them into a separate script to reduce loading overhead. It is recommended to keep the size of a single script within 1000 lines.

Furthermore, excessively long dependency chains should also be avoided to prevent 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 affected by this limitation.

4. Cases Where Scripts Are Not Divided

Although the previous sections discussed reasonable script planning and methods for calling between scripts, in certain specific situations (e.g., when the actual public functions used are few and simple), consider not dividing scripts and placing all code in the same script.

This approach, while introducing some code redundancy, also brings additional benefits:

  • A single script can run independently, reducing loading overhead.
  • Not affected by changes to public functions.
  • No need to consider dependency relationships when exporting scripts.

Please choose the most reasonable method for planning scripts based on the actual situation.

5. Shorthand for Mutual References Between Scripts Under the Same Script Set

Added in version 1.1.0rc51

References between scripts under the same script set can omit the script set ID part (i.e., only write the part starting with __).

This facilitates correct internal function references even after script set cloning changes the script set ID.

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 that can use simple procedural programming as well as object-oriented programming.

However, in DataFlux Func, it is recommended to write code in a more procedural style for ease of debugging, avoiding over-encapsulation.

For example, the same functionality can be implemented in two 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 style
def query_some_api(url, params):
    r = requests.get(url, params)
    return r.json()

# Object-oriented style
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 directly callable function, in the editor, you can select this function and directly fill in parameters to run it.

Whereas, to debug and run the do(...) method of the APIQuery class, you must first instantiate an object before calling it, thus requiring the additional test function test_api_query(...) to be written for invocation.

Please choose the specific method based on the actual situation.