Code Style & Standards
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The libfastjson project maintains code quality through a combination of mandatory style guidelines and automated Continuous Integration (CI) checks. While a formal, comprehensive coding style document is still under discussion by the rsyslog team, specific minimal requirements are enforced to ensure consistency across the codebase and to pass automated style validation during development.
The primary focus of these standards is to ensure readability, facilitate automated linting, and maintain high code quality through rigorous testing of all new functionality and bug fixes. All contributions must adhere to these standards to be considered for merging into the master branch.
Sources: CONTRIBUTING.md:1-25
Core Coding Guidelines
The project enforces specific formatting rules that are validated by CI scripts. These rules focus on indentation consistency and the removal of unnecessary characters.
Minimal Style Requirements
| Requirement | Description |
|---|---|
| Indentation | Must be done using TAB characters, not spaces. |
| Trailing Whitespace | No whitespace is permitted at the end of any line. |
| Line Length | The automated style checker enforces a maximum line length of 130 characters. |
Sources: CONTRIBUTING.md:23-25, CI/check_codestyle.sh:6
Automated Style Enforcement
Code style is enforced via a specialized tool maintained by the rsyslog project. The CI environment automatically clones a style checker and runs it against all source (.c) and header (.h) files in the repository.
The diagram above illustrates the automated workflow for verifying code style during the CI process.
Sources: CI/check_codestyle.sh:1-6, CONTRIBUTING.md:8-10
Testing Standards
Maintaining code quality in libfastjson relies heavily on a robust testbench. Developers are expected to provide automated tests for every change.
Test Requirements
- Mandatory CI Pass: All pull requests MUST pass all CI tests before they are merged.
- New Functionality: It is highly suggested to add related tests for any new functionality or bug fixes.
- Regression Testing: The
tests/test-defs.shscript provides a framework for running output-based tests and validating them against.expectedfiles. - Memory Safety: The test framework includes support for Valgrind to ensure no memory leaks or errors are introduced.
Sources: CONTRIBUTING.md:3-13, tests/test-defs.sh:75-120
Internal Debugging & Logging Standards
The project uses a standardized set of macros for internal debugging and error reporting, defined in debug.h. These macros are conditionally compiled based on whether MC_MAINTAINER_MODE is active.
Debugging Macros
| Macro | Maintainer Mode | Standard Mode |
|---|---|---|
MC_DEBUG(x, ...) | Calls mc_debug() | No-op (Optimized out) |
MC_ERROR(x, ...) | Calls mc_error() | Calls mc_error() |
MC_INFO(x, ...) | Calls mc_info() | No-op (Optimized out) |
Sources: debug.h:47-65
Release & Maintenance Standards
The project follows a strict checklist for releases to ensure versioning consistency and documentation accuracy.
- Version Management: Versions are updated in
json_c_version.h,Doxyfile, andconfigure.ac. - Compatibility: Shared library versioning (
libjson_la_LDFLAGS) must be updated according to GNU Libtool standards (x:y:z format). - Documentation: Doxygen documentation must be regenerated and committed for every release.
- Verification: Compilation must be verified on multiple platforms, including Linux and NetBSD.
Sources: RELEASE_CHECKLIST.txt:10-40
Conclusion
Code style and standards in libfastjson prioritize consistency and automated verification. By enforcing TAB-based indentation, a 130-character line limit, and mandatory CI testing, the project ensures that its goal of remaining a small, fast, and high-quality JSON library is met throughout its development lifecycle.