# Best practices for option naming?
**URL:** https://discourse.cmake.org/t/best-practices-for-option-naming/2039
**Category:** Code
**Created:** [October 21, 2020, 7:30am UTC](https://discourse.cmake.org/t/best-practices-for-option-naming/2039 "2020-10-21T07:30:36Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@bjornblissing](https://discourse.cmake.org/u/bjornblissing)
#### Post date: [October 21, 2020, 7:30am UTC](https://discourse.cmake.org/t/best-practices-for-option-naming/2039/1 "2020-10-21T07:30:37Z")
I recently came across this “problem” while I restructuring our source tree. Previously our third party dependencies were in the same repository as our own code and include by hand in our own CMake files.
We changed this to pull in the third party dependencies using git submodules and adding the dependencies in our project by using `ADD_SUBDIRECTORY` and then including the third party target with `TARGET_LINK_LIBRARIES`.
The first few dependencies worked fine to include like this. Then we got stuck with dependencies that had options which the exact same name, but quite different functionality. We have managed to fix these issues in our own code.
My question is more of a best practice nature: Should options in a library be prefixed with the library name to avoid name clashes? Or is there other ways to solve this issue?
---
### Author:  [@alex](https://discourse.cmake.org/u/alex)
#### Post date: [October 21, 2020, 8:23am UTC](https://discourse.cmake.org/t/best-practices-for-option-naming/2039/2 "2020-10-21T08:23:53Z")
I can’t claim to be an authority on the matter, but I try to name my project-specific options and cache variables as `ProjectName_VAR`. I also try not to introduce options that duplicate functionality with standard variables (e.g. `BUILD_SHARED_LIBS`). You can make use of function scopes to change these variables before the subdirectories see them and without affecting the current directory.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [October 21, 2020, 4:30pm UTC](https://discourse.cmake.org/t/best-practices-for-option-naming/2039/3 "2020-10-21T16:30:51Z")
Yes you should prefix cache variables with your targets/projects prefix.
This allows for the cmake-gui to also have nicer grouping, making a nice interface to the user.
This solution isn’t perfect for 100% of cases. But it handles most things.
Here is an example of 3 widely used open sourced projects that do this:
> **[glfw/glfw](https://github.com/glfw/glfw)**
>
> A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input - glfw/glfw
> **[microsoft/GSL](https://github.com/Microsoft/GSL)**
>
> Guidelines Support Library. Contribute to microsoft/GSL development by creating an account on GitHub.
> **[Neargye/magic\_enum](https://github.com/Neargye/magic_enum)**
>
> Static reflection for enums (to string, from string, iteration) for modern C++, work with any enum type without any macro or boilerplate code - Neargye/magic\_enum
