In the last lesson, we used the metaphor of “Hundred Family Surnames” to easily grasp the basic rules of C language identifiers. We learned that names must start with a letter or an underscore, can be followed by numbers, but cannot use keywords.

However, this is just the “beginner’s guide” to the art of naming in C. Did you know:A super long variable name might be a hidden BUG in some old compilers?

myVar and MyVar are completely different things in C?

Some seemingly cool naming conventions (like __my_func) are actually reserved by system-level vendors like Microsoft for their own “exclusive channels,” and ordinary developers should avoid them?

Today, we will delve into these areas that only “experts understand,” uncovering the “hidden rules” behind identifiers that concern code robustness and professionalism!

01

Too Long a Name? Beware of Being “Truncated”!

Let’s first discuss a point that is rarely mentioned today but is very important in the history of C language development: the effective length of identifiers.

In the old ANSI C (C89/C90) standard, there are clear limits on the length of identifiers:

• Internal identifiers: For variable names defined within a function, the standard guarantees only the first 31 characters are effective.

• External identifiers: For global variables or function names, the standard guarantees only the first 6 characters are effective.

What does “effective” mean? Let’s take an example:

Suppose there is an old system that can only record a maximum of 3 characters. Then “Zhang San, hello” and “Zhang San, you are bad” would be seen as the same person because the system would only record “Zhang San, you” and ignore the “hello” and “bad”!

Similarly, under a strictly compliant old standard compiler, if you define two external variables:

int very_long_variable_name_one;int very_long_variable_name_two;

Because their first 6 characters (very_l) are identical, the compiler may think they are the same variable, leading to subtle logical errors!

Professional Supplement and Deepening Understanding

Fortunately, we now live in a fortunate era! Modern compilers, represented by our commonly used **Visual Studio (Microsoft’s C/C++ compiler)**, have greatly relaxed this limitation.

Microsoft stipulates that for both internal and external identifiers, the effective length has been extended to an astonishing 247 characters. For everyday programming, this is more than sufficient, and we hardly need to worry about being “truncated” due to long names. Understanding this history helps us gain a deeper understanding of the evolution of C language.

02

Case Sensitivity: A Small Difference Can Lead to Big Errors

This is one of the most common mistakes made by beginners in C language, and it is a rule that must be remembered: C language is strictly case-sensitive.

This means that in the eyes of the compiler, even a single letter’s case difference makes them completely different identifiers.

int add;int Add;int ADD;int aDd;

In the above code, we have defined four completely different integer variables. Each has its own memory space and does not affect each other.

Important Warning

When writing code, you must maintain consistency in naming case. If you define a variable called userName and later write it as username, the compiler will mercilessly tell you: “Undefined identifier username,” because it does not recognize this “new name.”

03

Microsoft’s “Exclusive” Naming: Avoid at All Costs!

This is the essence of today’s lesson and an important dividing line between amateurs and professionals.

While we know that identifiers can start with an underscore _, certain specific combinations starting with an underscore are reserved for use by system and compiler vendors (like Microsoft). As application developers, we should actively avoid using them to prevent conflicts with internal macros or functions of the system.

Remember the following two “taboos”:Do not use double underscores __ at the beginning:

For example:int __my_var; (Highly discouraged!)

Microsoft stipulates that this naming convention is used to define its internal, non-standard, or specially significant macros and variables.

Do not use a single underscore + uppercase letter _A at the beginning:

For example:int _My_var; (Highly discouraged!)

This style is also heavily used by Microsoft in the internal implementation of its standard library.

How do we know this is true? Let’s take a “peek” at the source code implementation of the printf function (in Visual Studio), and you might see definitions like:

#define _CHECK_PARAM(expr) // ... Microsoft internal macro

Do you see? System-level code heavily uses these “underscore +” naming conventions. If we also name our code this way, it’s like walking in a minefield, and one day we might step on a “landmine” with the same name as the system, leading to various bizarre compilation errors or runtime issues.

To summarize, for the safety and portability of code, please adhere to the following naming conventions:

• Do not use __ (double underscore) at the beginning of names.

• Do not use _ (single underscore) + uppercase letter at the beginning of names.

• Although _ + lowercase letter at the beginning is allowed, it is generally recommended to avoid it unless you have a special reason.

The safest and most professional practice is to always start your identifier naming with a regular letter.

04

Summary

Through today’s in-depth study, we not only solidified the basics of identifiers but also mastered many important “hidden rules” in professional development.

Now, let’s review the key points:

• Length is no longer an issue: Modern compilers (like VS) support effective names of up to 247 characters, but understanding the 6-character limit of C89 helps us understand history.

• Case sensitivity is crucial: var and Var are two different variables, and precision must be maintained in programming.

• Avoid vendor “reserved areas”: Never use names starting with __ or _ + uppercase letters; this is the awareness of professional programmers.