diff --git a/docs/reference/contributing/guidelines/design_guidelines.md b/docs/reference/contributing/guidelines/design_guidelines.md
index 266e6287a7..cb0f56bddf 100644
--- a/docs/reference/contributing/guidelines/design_guidelines.md
+++ b/docs/reference/contributing/guidelines/design_guidelines.md
@@ -30,6 +30,7 @@ The Arm Mbed OS codebase is organized into conceptual submodules to limit the sc
 - As an entry point for the module (from the user space), we suggest a single header file. For example: `mbed.h`, `rtos.h`.
 - Header files should limit external includes to avoid indirectly exposing unrelated APIs. Header files should not expand namespaces.
 - In C++ modules, the API should be contained in a namespace that matches the module’s name. For example: `mbed::Ticker`, `rtos::Thread`, `netsocket::Socket`.
+- Define the internal class types in each C++ module inside an anonymous namespace. In C++, you cannot have different definitions of the same class name in different source files, even if they are not externally visible. In practice, a name collision often doesn't cause a problem; however, it can cause a build failure when link time optimization (LTO) is enabled, or a runtime failure if templates are instantiated using the internal classes. 
 - In C modules, every nonstatic function and type should be prefixed with the module’s name followed by an underscore. For example: `mbed_critical_section_enter()`, `lwip_gethostbyname(host)`.
 - A module contained in the Mbed OS codebase may be mirrored in a separate repo. The source repo should be clearly identified and linked to from the module's README.
 - Special directories should follow consistent naming convention.