# Feature request: Universal enforcement of CMake script formatting

**URL:** https://discourse.cmake.org/t/feature-request-universal-enforcement-of-cmake-script-formatting/4852
**Category:** Development
**Created:** [January 14, 2022, 10:33am UTC](https://discourse.cmake.org/t/feature-request-universal-enforcement-of-cmake-script-formatting/4852 "2022-01-14T10:33:46Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 18, 2022, 12:24pm UTC](https://discourse.cmake.org/t/feature-request-universal-enforcement-of-cmake-script-formatting/4852/4 "2022-01-18T12:24:09Z")

</div>

> [@benthevining](#):
>
> then a lexer/linter/formatter tool could use that information to provide hints or reformatting at each call site of said function

Just for the record, formatters usually don’t need to follow include paths to format the code. Since CMake files are rarely standalone, you also need to see what is included anywhere before the file in question is executed to peruse for such API docstrings for formatting help. Since `include()` usually relies on runtime manipulation of `CMAKE_MODULE_PATH`, a full CMake interpreter needs to be run to be a “formatter” (though a lint tool which does deeper static analysis would be able to do this).

Another case that came to mind are APIs that wrap another. They “skim off” a set of arguments and then pass the rest off to some other API. Getting such information is difficult. There’s also the “multiple arguments that take multiple values” where each instance of the keyword argument needs handled individually that `cmake_parse_arguments` just doesn’t handle today (IME, this is far rarer than the “wrapper” API).

---

_[View the full topic](https://discourse.cmake.org/t/feature-request-universal-enforcement-of-cmake-script-formatting/4852)._