注意安全……

@no1xsyzy

我没理解错的话，你说的重点是，你对代码风格的要求，细到了现有大部分工具都无法完美解决的地步，这是事实。然后你实解决的方式就只能是靠你自己去人工 Review 了，如果你们团队就是全靠你来 Review，而且你有话语权和精力一直做这个事，我当然没有任何意见。

我只是给你提供一个大部分团队（就我所知）都能接受的方案，即达成一份所有人能接受的规范，然后用一套自动化工具达到 90%的代码风格（可读性）需求，然后所有人忘掉这件事去做开发。

我们也遇到过自动化工具不能完美解决所有需求的问题，一些不重要又难开发的需求我们就放弃了，剩下的需求我用一些 ast 库补完了工具来满足。我们做 Review 时的 checklist 排除了所有 formatter，linter，sanitizer 能查出来的项，重点放在接口，安全，性能，架构（对于大一点的改动）。

PS. 之前说 column 是因为所有 formatter 都会支持，有些工具是能提供更细的选项的，比如制定函数传参是不是换行，dict 定义能不能换行，以及对于用户需要自定义格式的 region 提供关闭 formatter 的功能（比如手写矩阵的时候）

@no1xsyzy

1. 印象中单双引号这个大部分 formatter 不怎么管（ black 除外），一般 format 的时候会直接略过不处理（ as-is ），这个和你的风格并不冲突；
但你主题中的这个问题大部分 formatter 都可以统一解决，一个 column 限制就够了

2. 而且规范从来就不是用来约束某一个人，个人的代码风格和品味一直随着时间和能力改变，自己一个人写的项目从来不会有人关心是按着什么规范写的。
但既然你们都在同一份代码上工作，你是这么用引号以及长列表的，你的同事呢？你如何保证同事这么用？如果你保证不了，你同事的代码也许全是单 /双引号甚至相反的使用习惯，那你们阅读彼此的代码时也会难受啊？同事哪天改你的代码改成人家自己的“个人规范”了，你们打一架吗……规范就是用来提前避免这些的啊。（比较激进的 black 全给你 format 成双引号了）

这有啥好操心的……统一定一个 format 的规范然后让 ide / pre-commit hook 负责这个就好了啊……

@rabbirbot00 他们玩 beancount 的其实没几个“坚持”记账的，都是从各种信用卡账单，微信支付宝之类的定时导入、去重 ……

https://github.com/zsxsoft/my-beancount-scripts

用那些手机 app 一笔一笔记账的才是比较麻烦……

(可以试一下 lispy ……)

awesome 还是有用的，awesome-awesome 就算了，我又不是逛百货超市……

京东感觉用着没什么问题，而且说今天到就今天到。淘宝的界面感觉乱糟糟的。
买一些乱七八糟的东西，尤其是不在意质量的那种，还是会去淘宝，真是啥都有……

有这么费劲吗……我就 linux 下的 n 卡天天在用正常桌面+跑 cuda/opengl 啥的也没见过什么问题……

对应地设置结婚冷静期，从申请结婚开始同居半年以后双方同意才发结婚证，进一步降低离婚率。

一个多月，最近在玩大表哥和地平线 4

Windows 下对编码问题处理地比较好的免费压缩软件，也就是 bandizip 了，而且界面友好，有一些便利的选项。
(废都物语的贴吧汉化版需要用中文解压出乱码文件名才能玩，用日文编码解压出来，文件名是对的，反而不能玩了……)

Linux 下 unar 贼好用，也是自动检测编码。

这种问题很多文章了啊，比在这讨论靠谱多了 ……

https://herbsutter.com/2013/05/29/gotw-89-solution-smart-pointers/
https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/

而且涉及到真正需要管理 ownership 的地方都是要很小心做封装的，往上一层不涉及 ownership 的地方用 T* T& 传来传去就完事了……

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r3-a-raw-pointer-a-t-is-non-owning
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#fcall-parameter-passing

平时用 Win10 + Manjaro + Ubuntu，不谈游戏或者一些不相关的，只考虑开发体验的话，有一点我觉得比较重要的区别很少有人提，但是我现在都重度使用的话感受确实很明显：

https://github.com/Microsoft/WSL/issues/873#issuecomment-425272829

(虽然这个 issue 是 WSL 下的，不过这个评论讲的是 linux vs windows，我现在并不关心 WSL)

电视和 12.9 pro 都有。不过电视只有玩 ns 的时候用……电视打开太慢了……ipad 看视频很方便，想看个什么随手拿起来就能看。

Clean Architecture 不就讲了单一职责，开闭这些吗，这不是架构是啥？更原始一点的可以看 SICP

按照当时 Dropbox 的博客和后续的评价，他们的问题其实在于能搞定 C++ 框架的人跑了，现有团队 C++ 水平一般，而且看起来有些方向搞错了。

例如，他们提到的几个自己搞的库:

- json11 (为 c++11 开发的 json 库)

和 nlohmann/json , rapidjson 等比起来简陋太多了。这个库从 2013~2014 年开始在 GitHub 上维护。C++ 的 Serialization 库多如牛毛，json 库是打架最厉害的地方，不知道他们怎么想的要自己搞。

- 一套跨平台的 C++ 构建工具
"Most importantly, we needed a custom build system that created libraries containing C++ code as well as Java and Objective-C wrappers and could generate targets that were understood by both Xcodebuild and Gradle."
这种东西根本不是一个小团队能填完的坑……

跨平台里 C++ 应该承担的任务，我觉得 reddit 一个用户就说得很好：

> Slightly puzzled here, as it is not clear as what the scope of that C++ library is.

> I would expect dropbox to have a C or C++ cross platform library for its core behaviour (file content hashing, meta-data handling, sync configuration, thumbnail generation, indexing and searching, profile management, networking, caching, renaming, etc), and have it used on mobile and desktop platforms.

> Anything on top of that, like the model behind the mobile views, or the navigation logic, would be done in the native environment.

> From the look of it, it seems to me that they tried to implement pieces of the logic behind the UI of the mobile app in C++, and that isn't such a good idea. But I hope they didn't end up redoing all the core logic locally, that would be a waste.

> But still puzzled at the idea that the code that sync files may not be the same on all platforms...

https://www.reddit.com/r/cpp/comments/cqft4t/dropbox_replaces_c_with_platformspecific_languages/

在我看来，dropbox 这件事的意义在于告诉我们哪些地方尝试用 C++ 造轮子是坑，而不是“再也别考虑在任何跨平台应用里用 C++”. 不止是 UI 不应该跨平台写，所有不方便统一的 Native API 也要避免（例如它提到的“应用唤醒后台任务的 API”），这个不算 UI，但 platform-specific 的事情无论如何你也得写两遍，区别无非是 (Java/Kotlin 写一遍+ ObjC/Swift 写一遍) vs (用 C++ 写两遍然后用很难看的 macro/脚本 区分开)，前者毫无疑问会更清晰且更好调试。