工资都是线性的，期权股票才是重点

.editor onfig

牙得安 口腔溃疡 一滴灵

权力越大，责任越大

xps 2 in 1

我买了个提前购的椅子，结果 618 这两天便宜了一百多，申请价格保护，说是我用了优惠券所以不能保护。

等价
具体可以了解静态类型安全、泛型、型变

福娃

这待遇在成都很有吸引力啊

索尼手机最大的问题在于系统压不住国产 app

别想太多，努力赚钱，买房接盘，要不然现在买房得更焦虑。

1. 日常反思，反思了啥？
2. 和你条件差不多的，你们各自的条件是什么？你是怎么评价你条件差不多的？
3. 比你差的，差在哪里？基本交际原则都没有，那这些基本交际原则是什么？
4. 说再多，不妨放张自拍照骗，大伙好做客观评价

没有人接盘的房子就是厕所的纸

监狱各位有空去社区医院看看，见识一下这一批变老的坏人有多恐怖😱

建议穿 lo 裙

@kaedea
除了这个代码规范，类似的还有 git log 规范和 git merge /rebase 基本用法规范的问题，也真是难控制，通过 git hook 做强制检查容易，要引导别人按到新的流程去做事才是最难的。

个人觉得一个团队的整体工程师文化水平，从以上三点就能看出个大概了。

现在的感觉就是，要培养用户的习惯真的很难啊。

最近刚回在做代码格式规范的工作，说一下感受。

这个问题看上去简单，要做到强制还真的难：
1. 历史代码一大堆格式问题，全部修改不现实
2. 每个 ide 自带的格式化标准都不太一样
3. 代码风格每个人见解都有出入，很难完全统一

其实主要原因还是团队整体技术氛围，我之前呆过的团队，工程师文化比较好，大家普遍对代码质量有追求，所以风格统一上容易达成一致，新来的人代码写得搓也会在 rv 环节被纠正过来。

现在呆的团队代码风格就有点野了，历史包袱太重，大家普遍各顾个的，突然间要求别人要换成另一种写法，大概率会被白眼...

最终的方案是：
1. 合入检查只做修改、新增代码的格式规范
2. 代码规范只强制做结构上（空格、缩进）和命名上的要求单单这样就已经检查出不少问题
3. 通过 EditorConfig 统一项目的基本配置
4. 引导开发多使用 ide 的自动补全功能，已经提交代码前自觉格式化代码

但是我还是觉得之前团队的状态才是根本的解决方案啊，无奈。

@ChiangDi 和京沪深相比呢？