第二章：命名规范——代码的第一张名片

说实话，我见过太多项目，功能写得没问题，但一看代码就头疼。命名混乱、风格不统一，就像走进一个没有路标的迷宫。今天我们就来聊聊命名规范，这玩意儿看似简单，但真能决定一个项目的生死。

2.1 文件命名：项目的门面

文件命名，说白了就是给代码文件起个名字。我个人习惯用小写字母+下划线的风格。为什么？因为跨平台兼容性好，Linux 和 Windows 都不会出问题。

// 推荐
user_manager.cpp
http_client.cpp
data_processor.h

// 不推荐
UserManager.cpp
HTTPClient.cpp
DataProcessor.h

我在项目中遇到过一件事：有个同事用驼峰命名法给文件起名，结果在 Linux 上编译时，大小写敏感导致头文件找不到。排查了半天，最后发现是文件名大小写不一致。嗯，从那以后，我们团队就统一了小写+下划线。

2.2 类命名：用名词，首字母大写

类是什么？是对象的蓝图。所以类名应该用名词，并且首字母大写的驼峰风格。你想想看，User、HttpClient、DataProcessor，是不是一看就知道是什么东西？

// 推荐
class UserManager { ... };
class HttpClient { ... };
class DataProcessor { ... };

// 不推荐
class user_manager { ... };
class http_client { ... };
class data_processor { ... };

这里有个坑：抽象类或接口类，我建议加个 I 前缀。比如 ISerializable、IRepository。这不是强制要求，但能提高代码的可读性。

2.3 函数命名：用动词，小写开头

函数是动作，所以用动词开头。我个人习惯小写字母开头的驼峰风格。比如 getUser()、processData()、sendRequest()。

// 推荐
void getUser(int userId);
bool processData(const std::string& input);
int sendRequest(const HttpRequest& req);

// 不推荐
void GetUser(int userId);
bool ProcessData(const std::string& input);
int SendRequest(const HttpRequest& req);

我曾经在一个项目里看到有人用全大写的函数名，比如 GETUSER()。你猜怎么着？跟宏定义冲突了。所以函数名用小写开头，既安全又清晰。

2.4 变量命名：小写+下划线，见名知意

变量命名，我推荐小写字母+下划线。为什么？因为变量是最常用的，这种风格写起来快，读起来也清楚。

// 推荐
int user_count = 0;
std::string user_name;
bool is_connected = false;

// 不推荐
int userCount = 0;
std::string userName;
bool isConnected = false;

这里有个细节：成员变量我习惯加 m_ 前缀。比如 m_user_count、m_user_name。这样一眼就能区分局部变量和成员变量。全局变量加 g_ 前缀，比如 g_config。

2.5 宏命名：全大写+下划线

宏是预处理指令，所以用全大写+下划线。这是 C++ 社区约定俗成的规矩，千万别搞特殊。

// 推荐
#define MAX_BUFFER_SIZE 1024
#define PI 3.14159
#define LOG_ERROR(msg) ...

// 不推荐
#define maxBufferSize 1024
#define pi 3.14159
#define logError(msg) ...

为什么宏要全大写？因为宏没有作用域，全大写是一种视觉警告：小心，这是个宏！ 我见过有人把宏写成小写，结果跟函数重名，编译报错找半天。

2.6 命名空间命名：小写+下划线

命名空间用小写+下划线。比如 my_project、network_utils。不要用驼峰，也不要全大写。

// 推荐
namespace my_project {
namespace network_utils {
namespace data_processing {
}

// 不推荐
namespace MyProject {
namespace NetworkUtils {
namespace DataProcessing {
}

我个人习惯：命名空间跟项目名或模块名保持一致。比如项目叫 chat_system，命名空间就叫 chat_system。这样代码结构清晰，不会跟第三方库冲突。

2.7 知识体系总览

下面这张图，是我总结的命名规范知识体系。你可以把它当作一个快速参考。

2.8 总结

命名规范这东西，说白了就是约定俗成。没有绝对的对错，但一致性比什么都重要。我建议团队在项目开始时，就定好命名规范，写到 .clang-format 或代码规范文档里。

最后送你一句话：好的命名，让代码自己说话。 你写的每一行代码，都是在跟未来的自己对话。别让未来的你，看不懂现在的代码。

可可精品资料库