这有啥好操心的……统一定一个 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/脚本 区分开)，前者毫无疑问会更清晰且更好调试。

而且大部分连 ctrl f / find in page 以及多标签都做不到……比浏览器差太多了其实

没啥不行啊，在一些场景下可读性更好是肯定的，我觉得就是三点不方便，
一个是输入效率，大部分编辑环境对于拼音补全支持得不好，ascii 字符基本输入两三个就可以选到自己想要的了，
第二就是你这段代码其主要是数据定义，又比较好对齐，所以比较好看，可以放到更加复杂的逻辑（比如几层嵌套）中，看着其实会更混乱一些。
第三是没办法避免中英文混杂的问题，比如图中的“payment proportion” 和”in fact contact money last time”为啥不用中文呢，要么就是这是其他库的变量，要么这是团队其他人写的或者遗留代码，这是没法完全避免的。那你们的规范到底是什么时候用中文，什么时候用英文呢。

我对于任何编码规范的看法是，只要团队内成员能一致同意并且遵守，就没啥问题，比如你定大括号必须换行 /一行内的语句可以不用换行，缩进用 4 格还是 2 格，都会有人喜欢或者不喜欢，因为程序员审美观不同。上面说的后两点其实都是审美观问题，只要团队成员能接受并遵守一致的约定，那就没问题。

如果要解决第三个问题，可以给团队定一个专有词汇表（注释或者集中写一个 glossary.md ），项目内这些专有名词必须用这些文本表达。实际上我即使在纯英文的项目里都会这么干，一些容易引起混淆的词或者常用的缩写我会写在这里。比如我写一个图像处理程序，图像中间会经过各种变换，我可以定义，要求一开始输入的图像数据统一称为 input （而不是 raw, original, 原始图像, etc.），这样项目里 所有 input_前缀的都是代表输入的原始数据(input_dimension, input_height, input_file ），不会引起混淆。如果没有这类规范，可能就会在一个地方看到 raw_height, 另一个地方看到“输入图像高度”, input_rows ...
例如楼主的项目里肯定要约定，”实付工程款”这类概念(明显不止一个变量，在整个项目中会到处定义这类变量)，在能控制的代码里，必须统一用这五个中文字符，不允许用 payment 之类的代替，否则可能会引起混淆的，至少是可读性上的不便，因为看到 payment 和实付工程款同时出现的时候，我需要反应一下这是不是同一个概念（如果有的地方相同，有的地方不一样，那就很恶心了）

开源项目要面向全世界的话，那唯一能让大部分程序员都接受的规范也就是英文变量了

pep 8:

For Python 3.0 and beyond, the following policy is prescribed for the standard library (see PEP 3131): All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are not based on the Latin alphabet (latin-1, ISO/IEC 8859-1 character set) MUST provide a transliteration of their names in this character set.

Open source projects with a global audience are encouraged to adopt a similar policy.