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.

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.

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.

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.

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.