This document describes the code formatting standards for OBS Polyemesis and how to verify your code meets these standards.
OBS Polyemesis uses automated formatters to ensure consistent code style:
- CMake files: Formatted with gersemi
- C/C++ files: Formatted with clang-format
Before committing code, run the verification script:
./scripts/check-format.shIf there are formatting issues, the script will tell you how to fix them automatically.
# Install formatters
pip3 install gersemi
brew install clang-format# Install formatters
pip3 install gersemi
sudo apt install clang-format# Install formatters
pip3 install gersemi
sudo dnf install clang-tools-extra# Install formatters (using Python)
pip install gersemi
# Install clang-format
# Download from https://llvm.org/builds/
# Or use Chocolatey: choco install llvmRun the verification script to check all files:
./scripts/check-format.shOutput:
- ✓ Green checkmarks = All files are properly formatted
- ✖ Red crosses = Files need formatting (with instructions to fix)
CMake files:
gersemi --in-place CMakeLists.txt cmake/**/*.cmakeC/C++ files:
clang-format -i src/*.c src/*.cpp src/*.hYou can also fix formatting in your IDE:
- VS Code: Install "clang-format" and "cmake-format" extensions
- CLion: Built-in support, enable "Reformat Code" on save
- Vim/Neovim: Use plugins like
vim-clang-formatandcmake-format.vim
Single file:
clang-format -i src/plugin-main.c
gersemi --in-place CMakeLists.txtMultiple files:
clang-format -i src/restreamer-*.c
gersemi --in-place cmake/macos/*.cmakeThe GitHub Actions workflow automatically checks code formatting:
- Check Formatting workflow: Runs on every push and pull request
- Fails if: Any file doesn't meet formatting standards
- Passes if: All files are properly formatted
You can see the formatting checks in:
.github/workflows/check-format.yaml
Default gersemi configuration is used. Key conventions:
- 2-space indentation
- Function names in lowercase with underscores
- Variables in UPPERCASE
Uses the project's .clang-format configuration. Key conventions:
- Tab-based indentation (matching OBS Studio style)
- K&R-style braces
- 80-character line limit (when practical)
- Pointer/reference alignment to the variable name
You can automatically check formatting before each commit:
Create .git/hooks/pre-commit:
#!/bin/bash
# Pre-commit hook to check code formatting
./scripts/check-format.sh
if [ $? -ne 0 ]; then
echo ""
echo "Commit rejected due to formatting issues."
echo "Run the suggested commands above to fix formatting."
exit 1
fiMake it executable:
chmod +x .git/hooks/pre-commitInstall extensions:
code --install-extension xaver.clang-format
code --install-extension cheshirekow.cmake-formatSettings (.vscode/settings.json):
{
"editor.formatOnSave": true,
"C_Cpp.clang_format_style": "file",
"cmake.format.allowOptionalArgumentIndentation": true
}- Go to Settings → Editor → Code Style → C/C++
- Click Set from... → Predefined Style → LLVM
- Enable Reformat Code on save
Using vim-plug:
Plug 'rhysd/vim-clang-format'
" Auto-format on save
autocmd FileType c,cpp ClangFormatAutoEnableSolution:
pip3 install gersemi
# Or if using virtualenv:
source venv/bin/activate && pip install gersemiSolution (macOS):
brew install clang-formatSolution (Linux):
sudo apt install clang-format # Ubuntu/Debian
sudo dnf install clang-tools-extra # FedoraThese warnings about custom CMake functions (like _check_dependencies, target_install_resources) are expected and can be ignored. They don't affect the formatting.
Make sure you're using a compatible version:
clang-format --version # Should be 14.0 or laterIf the version is too old, update it:
brew upgrade clang-format # macOS- Run before committing: Always run
./scripts/check-format.shbefore committing - Format incrementally: Format files as you work on them
- IDE integration: Set up auto-formatting in your IDE
- Pre-commit hooks: Use the pre-commit hook to catch issues early
- CI/CD checks: Let GitHub Actions catch any issues you missed
When contributing to OBS Polyemesis:
- Ensure your code passes
./scripts/check-format.sh - Run formatters before creating a pull request
- Address any formatting issues raised in code review
- Follow the existing code style in the project