C++ 用尽可能多的 const 是好风格吗？

当然咯，只是很多人省事不加而已。

能用 const 的地方尽量使用 const 是一个好习惯，因为能避免意外的修改。
对 STL 来说也是一样的，容器内部数据的变动很可能造成迭代器的失效或者多线程访问时出现各种各样的问题，如果确定一个地方不应该对容器内部数据进行修改，那么就应该鼓励传入 const 引用。
当然，实际操作上还是得看具体的代码需求就是了。

大部分情况下、主流观点认为是是好风格（当然偶尔会看到一些也有道理的反驳观点）

只在关键的地方加也行，比如函数后面、局部指针变量，能够让编译器优化和避免一些低级错误。

@inhzus
比如？

支持禁用 const 关键字。

比较操蛋的应该是 const int *p, int * const p, const int * const p; 的理解。

@weeei 什么年代了还在用传统指针 （逃

指针的情况，类型开头那个 const （表示指向的内容不可修改）没问题，后面的 const （表示指针本身不可修改），多数时候用不上，写起来也麻烦。因为编译器是能知道你的指针有没有被重新赋值的，大多数时候你也不需要这个约束。

定义常量的话，用 const 当然也没问题，但 constexpr 可能更接近直观理解的那种「常量」。

给方法末尾加 const 是好习惯，否则 const 对象就无法访问这些方法了。

传参数的时候，传统意义上觉得写 const T&比较好，因为这样左值右值都能传，但如果你知道这个对象不是很大，直接按值传递 T 也是好的。

C++这个 const 明显比各种对象语义的语言更好理解（先不考虑 mutable 和 const_cast 的话），一旦 const 就是整个都不能修改。

@Lightbright 网上很多正确使用 unique_ptr 、shared_ptr 和 weak_ptr 的文章，想用好不容易啊

是。所以 rust 默认是 const 的，除非你显示的写明 mut 才可修改。当然 C++不能这么来，历史代码不允许这样的改动。
当然 C++还有 conprex ，能 conprex 的优先 conprex 情况变的更复杂（逃
dart 稍微好点用 final 关键字等价于 const auto

应加尽加

@Lightbright
去年接手过一段代码，是某个机床的输入设备的驱动代码，注释上的日期是 1982.06.。。。

flutter 就是各种 const ，当然对性能有好处的

喜欢加 const 那就加，无可厚非

虽然我个人不喜欢动不动就 const

我一般只对必要的加 const ，例如函数参数列表或返回值里的 const 指针或引用，const 常量定义，const 成员方法，const 类型转换等。基本不会对值传递的参数加 const ，也很少用 const auto 去接收函数返回值，有时候会用 const auto&接收返回值。

我是习惯先加，报错时再去掉

rust 默认就是 const

你要是确定能行就加。
就怕你自己稀里糊涂，今天加明天发现有代码编译不过去，还不知道得改哪儿。

现代编译器那么聪明（ clang ），我觉得他应该比我更懂 const ，所以我选择不加。

我以前也一直加，加到最后发现是给自己在设置编译障碍，干脆就不加了。

Best practice for const.
https://leimao.github.io/blog/Const-Pass-By-Value/

const is also very useful in many different applications in practice, in addition to the optimizations from the compiler:
https://leimao.github.io/blog/CPP-Const-Overloading/
https://leimao.github.io/blog/CPP-Const-Iterator/

Also do not abuse define in C++.

你把写代码看作是写文章，主要是你要表达的主义要丰富，合理，恰到好处

是的，「 Effective C++」中 条款 03 就是：尽可能使用 const

如果找不到理由不加 const ，那就加。搜索 const correctness

谷歌风格指南里写，函数参数若不是传出值的指针，则必须写 const 。实际上我会尽可能用 constexpr 吧。

@tool2d 相反，编译器又笨又保守(in a sense)，没有你的指示，根本不敢做任何优化。所以正确地使用`const`才能让编译器变聪明

比如在某个函数内，编译器无法保证其他进程不去改变`debug`这个 namespace scope 变量，就要傻傻地去生成 ASM 代码。加一条`bool debug_local = debug`就好了

```cpp
for (int i = 0; i < n; i++) {
...
if (debug) { // Global variable, can be possibly changed by printf
printf("The data is NaN\n");
}
}
```

不加，从来不加，C 本来就是需要修改各种变量的，除在形参以外的 const 毫无意义。

@dangyuluo 这情况要加 volatile ，让编译器不优化这个局部变量。

以前 gcc 很笨拙，毕竟那么多年的屎山。clang 不知道帮 gcc 填了多少坑。

就是因为经常有人讨论，加 const 是不是最佳实践
才会出现 rust 这种完全不信任程序员的语言。。。

@nuk c is not c++

一些常量一般我都加 const ，比如查表法算 CRC 的表，接收到的指令和回调的映射表，字符串。还有函数参数只输入的，加 const 后就可以同时接收 const 和非 const 的变量，通用型更强。

不但变量加 const ，成员函数我现在都能加 const 都加 const 了

@tool2d `clang`在处理这个问题上是一样的，也是不敢贸然优化。不是 GCC 的锅。

这里用 volatile 是错的思路。具体就不详细展开了，这有一篇很好的文章。
https://liam.page/2018/01/18/volatile-in-C-and-Cpp/

不过可以理解，关于 volatile 有太多错误的“讲解”了，很多人理解都有问题

我突然想通你为什么说用 volatile 了，因为我们讨论的问题不是同一个。我指的是如果编译器能确定 loop 里的函数没有 side effect 后，可以执行 Loop unswitching 优化。Local const 变量可以做到这点

https://en.wikipedia.org/wiki/Loop_unswitching

你指的是如何用 volatile “禁止”编译器优化掉`if(debug)`，从而每次循环都去内存位置检查`debug`的 most-up-to-date 值

实际上，ide 会提示你加 const 更好。。。

能加 const 就加，是好的編碼習慣。卻不是好的風格。
好的風格是，像某些其他語言那樣，變量綁定默認不可變。

const 具有传染性，除此之外都是提示和你协作的程序员或者是你自己的一种方法。如果和我协作的人能够清晰的知道自己要做什么，我不会加；如果是我自己开发我也不会加，除了这两种情况之外我会加 const

是个好风格，好处：
1. 提升编译器优化空间, 可以看 csapp 第五章了解如何写出编译器友好的代码
2. 提高可读性
3. 防止意外修改