Linting and Testing

Cecli can automatically lint and test your code every time it makes changes. This helps identify and repair any problems introduced by the AI edits.

Linting

Cecli comes with built in linters for most popular languages and will automatically lint code in these languages.

Or you can specify your favorite linter with the --lint-cmd <cmd> switch. The lint command should accept the filenames of the files to lint. If there are linting errors, cecli expects the command to print them on stdout/stderr and return a non-zero exit code. This is how most linters normally operate.

By default, cecli will lint any files which it edits. You can disable this with the --no-auto-lint switch.

Per-language linters

To specify different linters based on the code language, use --lint "language: cmd".

Code formatting “linters”

Many people use code formatters as linters, to format and pretty their code. These tools sometimes return non-zero exit codes if they make changes, which will confuse cecli into thinking there’s an actual lint error that needs to be fixed.

You can use formatters by wrapping them in a shell script like this and setting the script as your linter.

#!/bin/bash

# Run it twice.
#
# First attempt may reformat/modify files, and therefore exit with non-zero status.
#
# Second attempt will not do anything and exit 0 unless there's a real problem beyond
# the code formatting that was completed.

pre-commit run --files "$@" >/dev/null \
    || pre-commit run --files "$@"

Testing

You can run tests with /test <test-command>. cecli will run the test command without any arguments. If there are test errors, cecli expects the command to print them on stdout/stderr and return a non-zero exit code.

Cecli will try and fix any errors if the command returns a non-zero exit code.

You can configure cecli to run your test suite after each time the AI edits your code using the --test-cmd <test-command> and --auto-test switch.

Compiled languages

If you want to have cecli compile code after each edit, you can use the lint and test commands to achieve this.

• You might want to recompile each file which was modified
  to check for compile errors. To do this, provide a --lint-cmd which both lints and compiles the file. You could create a small shell script for this.
• You might want to rebuild the entire project after files
  are edited to check for build errors. To do this, provide a --test-cmd which both builds and tests the project. You could create a small shell script for this. Or you may be able to do something as simple as --test-cmd "dotnet build && dotnet test".

Manually running code

You can use the /run command in the chat to run your code and optionally share the output with cecli. This can be useful to share error messages or to show cecli the code’s output before asking for changes or corrections.

/run python myscript.py

Traceback (most recent call last):  
 File "myscript.py", line 22, in \<module\ 
   raise ValueError("something bad happened")  
ValueError: something bad happened  

> Add the output to the chat? y  

Tip:
You can also preface prompts with an exclamation mark e.g. !run python myscript.py.
Use double exclamation points (!!run python myscript.py) to suppress output capture
Use triple exclamation points (!!!sudo run python myscript.py) to suppress output capture and background the TUI for interactive commands