# KDE CMake Coding Style

## Indentation and Formatting

- Indent code inside control structures (such as `if()`, `foreach()`, `while()`) using spaces. Mixing tabs and spaces should be avoided.
- Use a consistent indentation width (e.g. two or four spaces) throughout a file.
- Place commands and their arguments on separate lines when they are long, to improve readability. Keep lists of sources or arguments one per line if it aids clarity.
- Put a space after command names and before the opening parenthesis; avoid spaces just inside parentheses.

## Command and Keyword Casing

- Prefer all-lowercase CMake commands (e.g. `add_executable()`, `target_link_libraries()`); other casing styles are allowed but do not mix different casings within the same file.
- Use lowercase for user-defined functions and macros as well, for consistency.

## Ending Control Blocks

- Close control structures with their matching end command using empty parentheses. Use `endif()`, `endwhile()`, `endforeach()`, `endmacro()` without repeating the condition or name.
- Always use an explicit `else()` when you need a branch, even if the branch is empty; this improves readability of nested blocks.

## Writing Find Modules

- When writing `Find<Package>.cmake` modules, ensure they can work even if `pkg-config` is not available; modules should first search without `pkg-config` and only use `PkgConfig` as a fallback.
- Use CMake’s `find_package_handle_standard_args()` helper to handle reporting of `FOUND` status, version and result variables.
- Avoid micro-optimizations such as skipping find logic when variables are already set; always run the full search to ensure correct results.
- Do not manually set `Foo_FIND_QUIETLY` to suppress messages; use the standard helper which respects the user’s settings.

## Other Best Practices

- Use variables consistently (e.g. camelCase or lowercase with underscores) and quote variables when their values may contain spaces.
- Place project-specific configuration in top-level `CMakeLists.txt` and keep module definitions (`.cmake` files) separate for reusability.
- Document non-obvious logic with comments; treat the build scripts with the same care as source code.