Checking source
In AEL, the Agent Engineering Language, ael check (command names may change before launch) will check your code without building or running it, and report every problem as a diagnostic that points at your source.
Status
Planned for AEL Beta 0.0.1. AEL is not available yet.
Usage
ael check
ael check src/nodes
ael check src/nodes/summarize.node.ael
ael check --target <target>
ael check --json
| Argument or option | Meaning |
|---|---|
[path] | The project, one folder of it or one source file. Without a path, the project in the current folder. |
--target <target> | The target to check for. Which target is checked without it will be described when the project settings are final. |
--json | Diagnostics in machine-readable form. See Diagnostics. |
What it checks
It will check that:
- Files and roles. The three root files are present, every other source file is named
<name>.<role>.ael, and each declares exactly one component whose name matches its file name. Extension files hold only private helper functions of their component. - Size. Every source file is within the size limit.
- Headers. Imports of reusable functions come before the first declaration and name files that exist; every export you select with
refer … select …is used in code that can run. - Visibility. Each call reaches a function the calling file is allowed to see: its own helpers, global functions of its folder and the folders above, and what it imports or selects.
- Types and ownership. Every value, input and output has the type its use requires, and ownership rules hold.
- Effects and capabilities. Each piece of code does only what it has been allowed to do.
- Hooks. Every hook exists, has the right type for where it is attached, and runs in a valid group.
- Configuration. Settings are known fields with values of the right type.
- Packages. Every package a file uses is declared by the nearest
pack.ael, locked in itspack.lockand installed. - The target. The target can offer what the program needs. A feature it cannot support will fail here, not on the device.
Every component will be checked, including those that main does not reach yet.
A folder or one file
A folder or a file will be checked in the context of its project. It will keep the global functions, imports and packages it inherits from the folders above it, so its result agrees with a check of the whole project. ael check and the build will run the same checks, so the two agree.
What it never does
- It will change no file, and never create a missing one.
- It will install no package and contact no registry: a package that is declared but not installed will be reported, with the command that installs it.
- It will run none of your code and no package code.
If a file changes while ael check is reading the project, it will report that rather than check a mix of old and new files. Run it again once your edits are saved.
Diagnostics
Each problem will be reported with its file, line and column, a message and, where it helps, the other places involved, such as the earlier declaration of a duplicate name. With --json, each diagnostic will follow the published diagnostic schema. Diagnostics describes both forms.
When any problem is found, ael check will end with a failure status, so an automated build stops there.
Related
- Formatting source: formatting will be separate from checking, and a formatted file may still fail a check.
- Reference maps: what references what, and what is unused.
- Files and roles and Functions and visibility: the rules the check applies.