有代码洁癖算不算是个好事

[loliordie]

我就有比较强的洁癖 要求实习生写 python 不符合 pep8 直接 close PR. 要求团队内部统一代码风格, 用拼音或者风格不一致的我会揪出来重点批评, 复杂一点的函数逼每个人都写文档 并且随改随更新.

今天上午又因为一个实习生使用git add *, 结果加进来一大堆临时文件发火了...感觉其他人都不理解自己好累...

[lululau]

怎么说呢，可以要求规范，经常提醒，但是发火当众点名批评什么的就有点莫名其妙了；你可能觉得这些是基本编码素质，但不是每个人都能达到你的编码水准，也不是每个人都是 50K 的薪水，对别人来说这些东西可能是个不小的负担，他能让他的代码运行起来可能已经拼尽了全部力量了

[scukmh]

ci + cr. ci 中的 test 加上代码风格检查就完了。

[upupddd]

@sockpuppet9527 赞

[ClericPy]

洁癖是病吧...

规范标准什么的是基操, 反正在好点的公司各种流程怎么走怎么顺, 也有专门的培训和集体 code review; 差点的公司就什么牛鬼蛇神都有了, 遇到这种情况除了抱怨, 也该想想自己为什么会与他们为伍

总结一句话, 都是来挣钱的, 没几个真来做技术的

[LokiSharp]

这两个不就是 reformat 和 gitignore 的事情么？写不好 gitignore 是 Team Leader 的能力问题吧

[DamienS]

只要不要发火其他都挺好

[cht]

看 lz 的描述只是很正常的格式要求呀，算不上洁癖
只不过许多人没有写干净代码的概念
解法就是找到志趣相投的人，避免给自己添堵 😁

[popbones]

对业务规范有较强要求是好的，但是直接 Close PR，发火或点名批品这种方式往往并不利于推广规范。

工作中感情用事很容易适得其反。目的是推行作业规范，不是斗气。

比如直接 Close PR 就不太友好，我们都是 CI 会检查规范等，不通过系统不允许合并，这样就排除了人与人之间的矛盾。

然后通过分享工具、IDE 配置文件的方式来自动化，让符合规范变得比不符合规范还省事。

如果这些都无法实行，那么说明团队中肯定有更深层次的问题，这个时候可能代码规范并不是最亟待解决的问题。

还有一个办法：换成 Go

[luckylo]

没人觉得有一个问题么。 既然是 实习生，没有带的么？带的人不跟别人培训下 git 也好，讲下 代码规范也好么

[liuky]

公司同事, 从不代码格式化 怎么破, 还不是要忍

[zdnyp]

严于律己，宽于律人

[xxdd]

实习生加个临时文件就能发火的···

[17681880207]

有代码洁癖绝对是好事，但是这个事情得要有个度。
比如可以要求一定程度上的代码规范统一，例如命名规范、符号规范等，如果要求别人的代码要和自己写的完全一样，那就过了。

[evilic]

洁癖不是好事，都已经是癖了，能是好事么……

代码规范就好。

洁癖容易走向过度设计……因为有时项目的规模原本可以很容易的就实现了，再按大项目的要求去管理，那得多做多少事情呀……

其实我个人觉得，代码的可读性更重要。

灵活变通一点吧。

[no1xsyzy]

@LokiSharp #105 话说我常常随手新建一个 e.py 来测试或者临时存放代码…… 这种真的可以写出正规的 gitignore 吗？
git add * 是真的对 git 和 shell 不熟悉，因为这个命令并不会 add 到 .gitignore 这个文件。
但我觉得 IDE 自带的 git 界面比较爽，可以比较容易地控制 commit 部分行。

[no1xsyzy]

@LokiSharp #105 漏了段，git add * 还不会 add 到被删除的文件。
就是偷懒也应该是 git add .

[no1xsyzy]

话说这么有洁癖，不如先推广下结对编程……
虽然敏捷那流我都不怎么喜欢，但其实是因为这都是解决 “编程以外的问题” 的。
代码风格通常是个协作问题，只有偶尔是个编程问题。

[wobuhuicode]

统一风格是一件好事。起码对团队来说是。
但是在团队中怎么把控这个代码规范是一个大问题。其实在 v2 也经常能看到一些人吐槽自己 leader 的一些古板规范。
我自己是列了很长的规范和理由出来的给团队执行的。有不服气某个规范的可以找我理论。

[cqy2016]

@DamienS #106 +1
道不同不相为谋

[fengerzh]

遇到这种问题，我都是把他叫过来，坐我边上，你活也不用干了，看着我，一行一行给你规范清楚了，羞愧不羞愧？不知羞耻的就直接辞退算了，爱干嘛干嘛去吧，反正别在我组里混了。