为何要在头文件的函数声明中为参数指定名称？

很多开发者会疑惑：头文件里的函数声明写参数名到底有什么用？明明无参数名的写法（不管是传统风格int sum(int, int)还是现代尾随返回风格auto sum(int, int) -> int）更简洁，甚至有人觉得带参数名的写法属于实现细节、不该对外暴露，刻意省略参数名还能倒逼自己发现抽象设计的缺陷。但从工程实践的角度看，头文件里的参数名有多个不可替代的实际价值，绝非冗余装饰：

参数名本身就是接口语义的组成部分，不属于实现细节 #

• 绝大多数同类型参数的场景下，光靠类型根本没法区分参数的实际语义。比如rectangle_area(int, int)，你不看文档根本不知道两个int代表宽和高、左上和右下坐标，还是边长和旋转角度；但如果写成rectangle_area(int width, int height)，哪怕不看注释、不翻实现，调用者一眼就能明确参数含义，完全不需要额外的文档解释。
• C++的语法设计从根上就没把参数名绑定为实现细节：你完全可以在头文件声明里写一套参数名，在对应的.cpp实现里用另一套和声明完全不同的参数名，语法层面根本不要求两者一致。这种设计本身就说明，头文件里的参数名从一开始就是写给接口调用方看的，不是给实现者的内部逻辑用的。
• 你提到的max_element(iterator, iterator)的场景，恰恰相反：如果把声明补成max_element(iterator begin, iterator end)，反而能清晰传递出“两个迭代器代表待搜索区间的首尾位置”的语义，根本不是抽象缺失的证据。你觉得这个接口应该升级为max_element(range)，是产品需求迭代的正常过程，不是参数名带来的设计冗余。
• 追求数学公式式的无参数名风格，只适合学术场景下的极简短函数，真进入工程领域的公共接口设计，没人会为了形式上的简洁牺牲调用者的可读性。哪怕是偏好现代尾随返回风格的写法，把参数名去掉写成auto sum(int, int) -> int，也不会比带参数名的auto sum(int a, int b) -> int更优雅——本质上参数名的价值和返回值的写法风格没有任何关系，该提升的可读性一点都不会少。

参数名直接决定了开发工具链的体验，是效率刚需 #

• 主流IDE和静态检查工具，在用户调用函数时，会自动从声明里提取参数名，把语义提示浮在对应实参的位置。比如你写rectangle_area(5, 10)，带参数名的声明会让IDE自动提示“width:5, height:10”，从根源上避免把宽高写反；如果声明没有参数名，工具链只能提示两个无意义的int类型，调用者根本没法快速校验参数顺序，写错的概率会大幅提升。
• 带默认参数、可变参数的接口，参数名更是工具补全的核心依据。比如声明void draw_window(int x, int y, int width, int height, bool resizable = true)，补全时IDE会自动把参数顺序、默认值按名对齐；如果没有参数名，补全出来的内容就是一堆没有语义的占位符，根本起不到减少出错的作用。

参数名是歧义消除的核心依据，尤其适合复杂重载和回调场景 #

• 当一个函数有多个同类型参数时，没有参数名根本没法区分语义。比如string::substr(size_t pos, size_t len)，不写参数名的话，没人能快速说清两个size_t哪个是起始位置、哪个是截取长度。
• 带回调的接口里，参数名就是回调编写者的公共契约。比如std::function<void(int err_code, int result)>，光看类型根本不知道两个int哪个是错误码、哪个是计算结果，库的作者哪怕为了省掉回调的文档说明，也一定会在头文件里把参数名补上，不然写回调的人全要靠试错摸顺序。

对“省略参数名倒逼发现抽象缺陷”的认知澄清 #

很多人觉得刻意省略参数名，能倒逼自己把接口设计得更抽象，实际上这个逻辑并不成立：

• 如果你写接口时想不出合适的参数名，本质上是你自己对接口的语义边界没有想清楚，根本不是“刻意省名字来倒逼设计”——真要设计出更好的max_element(range)接口，你自然会把参数换成范围类型，不会停留在迭代器版本。
• 刻意删掉参数名，只会增加所有调用者的认知负担，根本不会自动帮你优化抽象层级。你觉得参数名想不出来，应该反过来把语义梳理清楚，而不是为了证明自己的设计“够抽象”就把接口的可读性去掉。

内容的提问来源于stack exchange，提问作者Henk