Best Practices for Naming Template Parameters

Naming template parameters is an important aspect of writing clear and maintainable C++ code. While there aren't strict rules, there are some conventions that may be worth considering:

Single-Letter Names for Simple Cases

For simple, general-purpose templates, it's common to use single uppercase letters. For example:

• T for a general type
• N for a compile-time integral value
• E for element type in containers

1template <typename T, std::size_t N>
2class Array {
3  T elements[N];
4};

Descriptive Names for Complex Cases

For more complex templates or when the purpose of the parameter is not immediately obvious, use more descriptive names:

1#include <memory> // For std::allocator
2
3template <
4  typename ElementType,
5  typename Allocator = std::allocator<ElementType>
6>
7class MyVector {
8  // ...
9};

Prefixes for Different Kinds of Parameters

• T for type parameters: TKey, TValue
• N for non-type parameters: NSize, NAlignment

1#include <cstddef> // For std::size_t
2
3template <
4  typename TKey,
5  typename TValue, std::size_t NMaxSize
6>
7class FixedMap {
8  // ...
9};

Casing

It’s common to use PascalCase for type parameters and camelCase for non-type parameters:

1#include <cstddef> // For std::size_t
2
3template <
4  typename InputIterator,
5  typename OutputIterator,
6  std::size_t bufferSize
7>
8void CopyWithBuffer(
9  InputIterator first,
10  InputIterator last,
11  OutputIterator result) {
12  // ...
13}

Consistency with the Standard Library

If your template is similar to something in the standard library, consider using similar naming conventions:

1#include <utility> // For std::less
2
3template <
4  typename Key,
5  typename T,
6  typename Compare = std::less<Key>
7>
8class MyOrderedMap {
9  // ...
10};

Use typename Instead of class

While both typename and class are allowed, typename is generally preferred as it's more accurate (not all types are classes):

1template <typename T>
2class MyTemplate {
3  // ...
4};

Remember, the goal is to make your code as readable and self-explanatory as possible. Choose names that convey the purpose or constraints of the parameter. If a single letter suffices, use it. If more context is needed, don't hesitate to use a longer, more descriptive name.

Lastly, be consistent within your codebase or team. If your team has established naming conventions, follow those even if they differ slightly from these general guidelines.