以前刚开始工作的时候，天天被公司的 leader 嘲讽代码质量差，健壮性不强，也被公司的老鸟嘲讽很菜。
经历过一番历练，渐渐有了提高代码质量的意识。
换了一家公司后，公司里面还是有我之前以为的“大牛”，老大哥行为处事很“高调”，到处找人“改代码”，批评别人这里不对，那里不对，我承认他的代码水平很高，能解决很多问题。
技术上的问题，确实值得佩服，但是真正震撼我的是“精神”，一种很难去定义的“精神”。
公司里有一位搞嵌入式和图像处理的老工程师（所以他是写 C/C++的），之前跟他交流不多，他为人也很低调，他基本上一直沉浸在自己的代码世界里。
直到有一次，有个项目，我跟老工程师要互相调用自己写的模块，他代码确实写的很好，但是让我佩服他的是他的“适应能力”。
公司也没有一个统一的说明文件，必须要用哪一个代码标准。举个最简单的例子，就好像他习惯了
if(){

}

而我因为习惯了 VS 的 IDE，也写过一段时间的 C＃，所以一直都喜欢下面这种写法
if()
{

}

而他在用我的“编码规范”下，（有些是我自己都觉得烂），他依然很迅速的适应了我的写法，按照我的习惯，快速且成功的写完了需求。如果是“老大哥”，可能会把我的代码先改一遍，然后批评我这里不对，那里不对。
说实话，我真的很惭愧，老工程师从来不抱怨别人的代码，怎么样思维混乱，怎么样命名不规范，怎么样性能差，虽然他也有自己的习惯，但是不至于“强迫症”到让人必须像他那样写，也不重新打乱别人写完的代码，而是以工作为主，快速适应。
由衷的佩服他，佩服他的纯粹，不多说什么，只是默默地写代码，完成需求。

我的举例不恰当，引起了大家的误解。
代码格式化的问题，VS2017已经很好了，只需要“；”和“}”即可。
因为工作的关系，所以模块的设计，逻辑处理还有接口设计比较重要。

说的不太恰当，“吃屎不嫌屎臭”，这种人怎么评价？

说明你们缺乏代码规范和 lint 工具

你说的是代码风格，而不是规范吧

自己修行不够

嗯，是的

是代码风格

代码风格问题不是 IDE 或者脚本一键格式化的事吗…这也能批评别人就离谱…

代码风格的问题应该用工具去解决吧

由衷的佩服他，佩服他的纯粹，不多说什么，只是默默地写代码，完成需求。

做一天和尚撞一天钟。对这种人不能期望更多。

和追妹子很相似，妹子能主动跟你说几句，大概还有戏。
第二种你怎么使劲面对的都是顽石一个，舔都不知道从何处舔。不拒绝，不负责。食之无味，弃之可惜。

我从来不和同事说你的代码差，只在论坛水群里吐槽，
得有多脑残，才会给自己的同事说，你的代码稀烂

人之欢在好为人师
人之患在好为人师

他是混明白了，反正就是的打工仔而已。
如果他是 leader，那必然会让你规范代码。
不在其位不谋其职罢了。

我的第一份工作，leader 就告诉我：好的代码风格就是写得和原作者看不出来区别，至今受益颇深

你這舉例沒說服力呀.

代碼風格沒有對錯.
但拼錯字, 有對錯.

照着原来的代码写，这是非常容易的事情啊，把你的代码改一遍才是额外的工作…… 我接手老项目或者和别人协作也大多这么干，别人怎样我就能怎样，但不妨碍喷有些实在很糟糕的代码

代码风格明明是工具可以控制的.

我就是那种代码风格也会给同事建议的人……，这个我也就提过几次让尽量按阿里巴巴规约来就没再说过了。但是关于代码怎么写这块我会多次重申，例如同事老是喜欢复制粘贴，一大块代码明明只是里面一两个参数不同，他的选择是复制粘贴然后 if else，影响了我排查 bug 效率这种绝对会提。

还是太闲了。现在一个项目的生命周期撑死两三个月，完成需求就行了。it works

写代码也要向龙哥学习，be water 。别人怎么写你也怎么写

感觉代码风格和合住的公共卫生很像。
卫生习惯差肯定不对，但合住的人都不介意，就不是什么大问题。
都爱干净当然更好。最麻烦的是一部分人介意，另一部分人无所谓。
至于爱干净那个，是自己默默迁就，主动打扫，还是天天在室友耳边唠叨，还是跟外人抱怨，看个人性格。
也不排除有些人并不是多爱干净，只是爱抓住一切机会教训人。

真正的软件开发人员的专业是，既不是你去适应老大哥，也不是让别人适应你，而是你们共同遵守一套规范和标准，目的是保证高效协作以及代码的可维护性，这是团队协作所必须的契约精神，他比任何个人的小情绪更重要。

纵观那些优秀的开源项目，哪个不是严格遵守一套规范去维护和贡献代码的，如果仅凭个人意愿在这种事情上东拉西扯，那项目更本无法长期进行下去。

文不对题

［为什么代码写得差还不给吐槽］

你对代码差的理解和我不太一样
if () return
if () { return }
if (a > b) {return true}

前两个算是风格问题，那第三个呢？

代码风格和烂不烂有啥关系啊。

如果代码烂就要认，没必要批评比你做的好的人

心疼 lz 没用过 lint
真正的强者应该写 lint rule

这个在 lint 普及前我也会指出的。还包括命名，缩进等等。现在有 lint 了，大多都自动处理了。

这不是我理解的“代码风格”…

。。。这他妈把我看呆了

我觉得很多时候，把几个事情揉在一起是一个很有趣的事。

我感觉是

• 技术强是好的；
• 帮助别人是好的；
• 恃才傲物是不好的；
• 知错不改是不好的；

但是这里通过某种逻辑嫁接，把跟着吃屎（如果真的是不好的东西）当做是对的，那这个事情本身就是很傻逼的事情；

===========

又，规范的东西，不是通过人主观的约束，而是通过工具来实现；

===========

又，很多时候，写代码的洁癖是看情况的，大家都知道吃屎是不对的，偶尔不得不吃屎的时候，应该明白有时屎在某种程度上是可以避免的。
而不是纵容自己，吃屎习惯就好。

很多时候防御性编程是必要的，这是为了保护好的代码，不是为了洁身自好。
人掏粪的时候戴手套是好的。

修改现有模块，沿用原有的代码规范。这本身就是代码规范中应该有的一项。

第三个实际上也是代码风格的问题。编译器早就给你优化掉了。
顺手就改掉了，没必要去说别人。

LZ 了解一下 linter 和 formatter 。做这个真的不费劲。想适配什么风格就能什么风格。

那啥，修改代码要保证最少，这样版本控制在 diff 的时候才能一目了然。修改原有格式就乱套了。

我一般不会主动去帮别人改，技术强也好，在工作范围内是有边界的，也许你的帮忙让别人很烦。
除非是别人明确需要帮忙 or 自己主导的项目才会提建议，都是打工人而已。

其实你还要从这么个角度考虑，老工程师可能只是为了尽快为了配合你完成这个任务，那么过多的说教对他来说是吃力不讨好的事情，有些事情也不是短时间能搞定的，可允许的范围，没必要死扣。
至于你的那些技术大拿，技术可能性，但是培训人的能力欠缺，只会怼人的领导，也只能管几个人，人管多了，项目就会炸。

前同事的代码层层嵌套，过度包装，离职我来改，恶心死我了，真滴晦气

团队合作的第一步不就是统一编码规范&风格？

我是非常讨厌那种图自己省事的烂摊子

说明你们的团队没有规范。

多年后, 当你接到一套 N 手代码, 改一处到处漏, 就是你骂人八辈子祖宗的时候了.
没错,可能这代码就是你当年写的.

代码烂就是得 review+lint+unit-test

lint 工具是摆着好看的么
没有一个统一的编码规范 应该是技术部老大出问题了。。

我这写的是不是有问题（小白）-->也许还可以这么写（进阶）-->你们写的太烂（伪大牛）-->放着我来（大牛）-->按你能理解的方式来（隐退）-->就一谋生工具（万法归一)

公司付钱了吗，付钱给你 你拿了吗，你拿了还说什么
就是付钱来让你接手烂代码，行不行？你是以为付钱让你享受工作来了吗

当然 享受工作的岗位也有，不是你的

1. 根本原因是你们的 leader 没有尽责.
2. 如果我是"老大哥", 我会说服 leader 落实编码规则.
   如果我是"老工程师", 我才不胡惯着你. 公司不需要老好人.
   如果我是你, 我不会来这抱怨, 自己代码没写好, 被别人指出, 那是我的荣幸.
   "老大哥"和"老工程师"技术都好, 一个指出你的问题, 一个顺应你的风格, 你就对他们表现出不同的态度, 你可能需要反思自己.
   另外, 代码规范与风格是两码事, 这两个人比较不合适.

我没看懂，你似乎很反感别人用自己的习惯要求你， 但按帖子中的描述，你好像正在做同样的事？

“老大哥”为了你好，教你怎么写。你偏不听。

能影响你的代码产出质量的都是细节。而老大哥无私的教你。

我不相信，他批评你，每次都说你的代码缩进用的不对，括号换行有问题。

人家肯定会给你指出哪里逻辑需要完善，还有更好的写法。

你自己满足于把功能实现。就不要怪别人说你。把功能实现，和把功能实现好是两码事。

领导肯定都希望组员写出易于维护的代码，而不是你各种奇葩逻辑一堆，只要功能完成就了事。

这个才是正解...

之前大牛改我的代码,让我一度认为是自己写的...

但是明明自己没写过啊.

还没到大牛阶段已经开始隐退了😓
这叫编码规范? 如果有人这么说我, 我一定觉得这家伙水得一匹. 你说把一堆 if 优化得少少看起来清爽一些那还差不多

那你肯定是大牛了，比较能理解别人的程度，还能按别人的能理解的程度写，水平都很高，类似你已经看穿别人了。