推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 1637 天前的主题，其中的信息可能已经有所发展或是发生改变。
我就有比较强的洁癖 要求实习生写 python 不符合 pep8 直接 close PR. 要求团队内部统一代码风格, 用拼音或者风格不一致的我会揪出来重点批评, 复杂一点的函数逼每个人都写文档 并且随改随更新.
今天上午又因为一个实习生使用git add *, 结果加进来一大堆临时文件发火了...感觉其他人都不理解自己好累...
第 1 条附言 · 2020-07-01 11:18:52 +08:00
补充一下
我要求 PEP8 语法的同时也会告诉实习生在 IDE 里面使用 FLAKE8 等插件高亮错误语法 gitignore 我也会尽可能写好(由于项目的特殊性无法使用白名单模式)
但是总有那种在学校养成坏习惯整个代码写的叫一个突出自我的人 还特别难改
我要求 PEP8 语法的同时也会告诉实习生在 IDE 里面使用 FLAKE8 等插件高亮错误语法 gitignore 我也会尽可能写好(由于项目的特殊性无法使用白名单模式)
但是总有那种在学校养成坏习惯整个代码写的叫一个突出自我的人 还特别难改
 |
1
RicardoY 2020-06-30 23:02:03 +08:00 via iPhone  21
应该写 gitignore 解决临时文件的问题吧...这应该不能怪到实习生头上...
|
 |
2
Jooooooooo 2020-06-30 23:06:12 +08:00 4
算好事, 风格统一易于维护, 而且你有实权要求是最好
不过能用系统去解决的问题不要用流程解决 比如不符合你说的那个规范的代码用插件在开发时就提醒, 不要到了提 pr 阶段再打回去, 多浪费时间呀 还有 git, 这个用 gitignore 去解决呀, 手动 git add 具体文件很傻 |
 |
3
jinsongzhao 2020-06-30 23:07:38 +08:00 1
你已经反问自己了，还问啥呢？物极必反，平时可以多多要求，但赶时间时，就别干扰推进速度，反正吃了苦头，就会改进，有难同当，拿得起放得下。
|
 |
4
namelosw 2020-06-30 23:08:35 +08:00
挺好的，但是这个东西首先得给他们足够的资源，时间，如果因为这些做不完加班加到组员都上肯定都是不想做的。
其次就是文化上的，光跟别人吼没用，得培养出来这种文化，把超过半数的人都培养成代码洁癖，以后就容易保持了。只有不到半数的人坚持，就是很吃力。有点像文明系列的宗教，有传染性，主流宗教先手就比较好过。 |
 |
5
loliordie OP @RicardoY 我写过了 但是因为项目文件很杂没法用白名单 每个人开发环境又不同 总有漏网之鱼 我说了很多次了又不是 ios 这种自动生成一大堆文件的项目 就一个后端系统 改的不多 改了啥 add 啥就行了.
|
|
6
namelosw 2020-06-30 23:12:44 +08:00
如果有一些实权，可以先把规则都定下来，试着让组员轮流值日，比如每周轮换，到了这周这个人负责这些风格问题，你尽量少插手。
总有别人帮他做决定的时候，他就不会去想这些问题，就会觉得这些都是规定，你们就成了阶级敌人了。 反过来，一个人自己完全负责某些事情的时候，他的思想就容易从这个事情上开始出发，这就是所谓的屁股决定脑袋。 |
 |
7
seliote 2020-06-30 23:12:47 +08:00
深有体会。但是规则是用来约束自己的。
|
 |
8
newtype0092 2020-06-30 23:15:18 +08:00
我也有点，每次看新人提的代码都有点头疼，有些不合适的零零碎碎的语法、风格、不规范命名都很难受，我一般开始会严一点，把问题集中说几次，之后如果问题多了就让他们改去，偶尔漏了的就忍了，提醒下让下次注意。
就我当初实习的时候被 review 的死去活来的经验来说，越严格的 review 并一直坚持，再坏的习惯都能改过来，如果还改不过来那就是真的不上心了，这种人趁早踢掉，因为这种心态什么事都做不好。 不过说实话这种东西到底自动化才是正道，能用插件用插件，特殊的自己写 hook 检查，这样起码不会再因为这些杂事浪费自己的时间了，只要自动化检查做的好“代码洁癖”和“不拘小节”的人也是能和睦相处的。 |
 |
9
linvon 2020-06-30 23:18:08 +08:00
git add * 也太有问题了
|
 |
10
lenqu 2020-06-30 23:52:49 +08:00
@linvon git add * 没有问题，是不会 gitignore 的问题，或者是太懒，以及不使用 ide 自带的 git workflow
|
|
11
RicardoY 2020-07-01 00:48:09 +08:00 via iPhone
@loliordie 你可以维护几套常用的开发环境的 gitignore，比如 pycharm&vscode 的..然后不允许实习生用别的开发环境吧...pep8 的问题应该用钩子解决...我感觉你说的这些问题靠 review 解决起来会非常痛苦，应该引入自动化的强制约束...
|
 |
12
msg7086 2020-07-01 01:21:34 +08:00 via Android
|
 |
13
ericls 2020-07-01 01:48:52 +08:00 7
作为一个 lead，你应该清楚工具比人靠谱。
PR 本来的作用就是给你 review 的，你就好好 review 就行了，有什么 feedback 发表就行了，别带那么多情绪。 |
|
15
ericls 2020-07-01 01:55:35 +08:00 2
如果说你工作目标的一部分就是保证代码风格，那你就应该做工作去保证代码风格，不管你是用自动化工具也好，集体开会说明也好，一对一开会也好，或者建立什么别的机制都行。但是你内心上不能把这件事情当成别人理所应当承担的责任，这是你的工作。
|
 |
16
ericgui 2020-07-01 02:13:28 +08:00
你要是组长，你想怎么玩就可以
但你也要负责这个后果：组员恨你，离职，进度跟不上，自己压力大等等 |
 |
17
supermoonie 2020-07-01 02:25:19 +08:00 via iPhone
约束大于规范，别人说我就听，虽然和我的规范不太一样，慢慢也就适应了
|
 |
18
zhengjing 2020-07-01 07:47:06 +08:00
@loliordie 你这种对没有心的人没用，反而会把自己搞的很累。同意楼上的，自己把系统搞好，gitignore 应该由你整理好，把所有情况都考虑进来，如果自己偷懒，那怪不得别人哦~
|
 |
20
zwater 2020-07-01 08:17:51 +08:00
不是好事，除了自己暗爽以外。
我有类似的公文格式洁癖，正文仿宋 GB2312，一级标题黑体二级标题楷体加粗三级标题仿宋 GB2312 加粗行间距 30…… 每次写稿都特别慢。 |
 |
21
dustinth 2020-07-01 08:20:23 +08:00
.gitignore + git precommit hook(lint integration), 既然要求那么高,为什么不对自己要求高点, 把这套工具给整齐了?
|
 |
22
tenca 2020-07-01 08:22:19 +08:00 1
代码洁癖算是个好事，除非你认为代码洁癖是个好事情。
|
 |
23
opengps 2020-07-01 08:25:23 +08:00
刚开始是好事，后来逐步到了管理团队的时候就暴露弊端了
|
 |
24
afx 2020-07-01 08:26:57 +08:00 via iPhone
是好事
|
 |
25
inhzus 2020-07-01 08:33:05 +08:00 via Android
ci 上加上 pep8 的检查，过不了直接自动 close
|
 |
26
jay4497 2020-07-01 08:38:01 +08:00
洁癖没什么好坏，别强加给别人就好。不过像工作环境这种有利益关系的场合，当然是谁权利大谁就为所欲为了。。。
|
 |
27
StarUDream 2020-07-01 08:47:46 +08:00 via Android
我觉得这完全不是洁癖啊，这不是最基本要求吗？
|
|
28
StarUDream 2020-07-01 08:49:34 +08:00 via Android
提出来觉得不适合，直接写 ci lint，强制改。
|
 |
29
lamy 2020-07-01 08:50:45 +08:00 via Android
git add 完还要再 diff 一次自己 review
|
 |
30
ibegyourpardon 2020-07-01 08:52:48 +08:00
我觉得，你累……活该。
这和洁癖没关系。 道理千万条，但你选择靠人肉和规范来解决问题。 人是靠不住的，只有工具可以。 你应该用工具来解决。 所以目标上，我相信大多数人都认同你。 但这个思路上，完完全全你就错了。 或者说有规范也可以，但必须有对应的工具配套。 也即，如果你不按规范来，你的代码提交不了，你的系统给你报错，总之你就是不行。而不需要人肉来打回，核实。 |
 |
31
nightwitch 2020-07-01 08:58:20 +08:00
洁癖可以，但是你应该引入自动化工具来审核。
|
 |
32
yuanfnadi 2020-07-01 08:59:30 +08:00
说说前端
1. 项目有 eslint ,代码不规范无法 commit 2. 项目有 CI，CI 不通过拒绝 CR 3. gitignore 解决临时文件问题 python 应该也有类似工具 |
 |
33
yousabuk 2020-07-01 08:59:52 +08:00 via iPhone
好事，做软件就得有尽善尽美的意识。
胡日鬼倒棒槌可不行 |
 |
34
bintianbaihua 2020-07-01 09:02:35 +08:00
算好事，可以在团队分享这样的好处，让大家知道一些规范， 推广肯定是需要时间的。
|
 |
35
Flourite 2020-07-01 09:04:50 +08:00
不算，因为可以用工具解决你的问题，你的关注点应该在其他地方
|
 |
36
shunconf 2020-07-01 09:08:49 +08:00
git add . 省事，或者 git add *.py 咯
|
 |
37
liunian1004 2020-07-01 09:09:13 +08:00
看处于什么环境和价值观，如果大家都不在乎，你会觉得很累
|
 |
38
Leonard 2020-07-01 09:09:22 +08:00
对自己算好事，要求别人就不好说
|
 |
39
cominghome 2020-07-01 09:13:06 +08:00 1
我有洁癖，而且是比较严重的那种。IDE 上见不得一点提示，哪怕是拼写检查。而且热衷于前期 review，功能实现完只要没到 deadline，就开始瞎鸡儿优化代码结构（其实一开始就一两个类，整个鸡毛 mixin ），出活效率奇低。
|
 |
40
littleylv 2020-07-01 09:15:06 +08:00
洁癖没问题，但“揪出来重点批评”，“逼”，“发火”……
发火，还是对一个实习生发火……好好讲不行吗？ |
 |
41
nicevar 2020-07-01 09:19:16 +08:00
不是什么代码洁癖问题, 就你自己的描述来看明显你们的 git 流程有问题, 实习生提交的代码你们不审核直接就合并了? 还是都没有创建分支, 抱团开发? 这些都没弄好, 把锅丢给实习生不合理
|
 |
42
STRRL 2020-07-01 09:29:31 +08:00
是好事
|
 |
43
levelworm 2020-07-01 09:46:51 +08:00
是好事，不过发火没必要。另外 git 不加临时文件等等我倒是觉得的确比较重要，楼上说的审核也很有道理。
|
|
44
levelworm 2020-07-01 09:52:09 +08:00
@Jooooooooo +1 。能用系统解决的最好。
|
 |
45
wolfie 2020-07-01 09:53:46 +08:00
git add 肯定有问题，如果临时修改配置文件测试用直接提上去？
|
 |
46
kzfile 2020-07-01 10:13:10 +08:00
有个完善的脚手架可以让人养成代码洁癖
|
 |
48
hantsy 2020-07-01 10:15:31 +08:00
规则是必须。虽然不必要求太苛刻，但是不成规矩，不成方圆的道理，大家都懂。
1. 简单开发文档说明统一遵循的约定。应该配置代码静态检测之类的工具，Git 嘛，最基本的 Github FLow 吧（ Branch 基础）。最好参加一些国际上认可的代码规范，然后定制，这点我讨厌一些自己创造（看到很多人搞出来的笑话）。 2. 一开始就使用工具配置强制要求，而不是靠嘴巴，流程做到位，让偷懒，摸鱼，打酱油的行为无处可藏。我这个人特别讨厌绩效考核，但是之前一些经验告诉我，对于一些懒散的第二次犯同样问题的人，绩效是个很好的东西。 你说的这个 Git Add 的代码怎么会直接合并进去 Master ？我不明白这是什么操作？没有分支？没有 Code review ？没有 CI ？ |
 |
49
soulmt 2020-07-01 10:18:08 +08:00 1
洁癖是好事，但是用这种方式管理，很明显有问题， 你可以针对规范开个小会，得到大家对规范的认可，或者用脚本检查语法规范，合格了才可以 commit，方法很多
|
 |
50
ghwolf007 2020-07-01 10:20:31 +08:00
感觉对手下人是好事 我多希望刚毕业能碰到这种团队 结果散养到现在 唉
|
 |
51
sanqian 2020-07-01 10:23:33 +08:00
好事吧，对实习生也挺好的。但是为了这个对其他人发火的话没必要吧 实习生也需要点时间去适应你？
|
 |
52
mahone3297 2020-07-01 10:24:08 +08:00
好事
不然，他离职了，还是要你处理吧？线上出问题了，开发的人不在，你肯定要紧急处理，看不懂代码，怎么办？ 所以，还是平时要求把。。。 |
 |
53
hsk9044 2020-07-01 10:25:30 +08:00
规范是好事, 如果刚开始没有养成习惯, 后面等老油条再改回来更麻烦
|
|
54
hantsy 2020-07-01 10:33:15 +08:00
@namelosw 人工监督方式没必要的。
我一直推荐强制用工具来约束。 代码都是可以 Code Review，在 Github PR （其它的专用 CR 或者 GitLab 也类似）上，人人都可以针对某一行代码，某个文件，扯断进行否决，或提修改意见。技术这东西还公开讨论比较好。 国内最怕的是某些人本来就平时懒散成性，加上心胸狭窄，最后成了拉仇恨，变成人身攻击的可能。 |
 |
55
zzzmj 2020-07-01 10:33:27 +08:00
代码洁癖，不要上升到钻牛角尖都可以接受，至于统一代码规范，可以用一些 ci+lint 工具，挂了不给过就好了。从小抓起还是最省事的
|
 |
56
Nostalgiaaaa 2020-07-01 10:34:36 +08:00
工具比每天开会好用不少。配置下 pre-commit，.gitignore，写点 pylint 插件，加上 ci 或者 action 基本解决你现在描述的问题。
|
 |
57
TangMonk 2020-07-01 10:38:11 +08:00 via iPhone
严格是好事，但是发火不是好事。
不应「违逆我者则生嗔恚」。 |
 |
58
libook 2020-07-01 10:41:01 +08:00 1
分情况。
1. 要依照具体情况制定标准。举个例子，代码缩进，后端代码逻辑复杂，且每一行不会太长（很多语言长语句拆成多行阅读更清晰），强化视觉层级可以加强代码可读性，所以可以考虑缩进四个空格；前端 HTML 代码可能因为标签属性较多，每一行都会很长，所以为了尽量避免折行，可以考虑缩进 2 个空格，甚至 1 个。（当然，可以换成 Tab ） 2. 制定标准要有理有据，不能作为信仰开圣战，也不要盲从大公司、大牛、著名项目。比如有的人见过 StandardJS （注意这个不是 JS 官方标准）之后就唾弃一切在末尾加分号的行为，但忽略了之所以可以不加分号是因为有 StandardJS 的 Linter 在排雷，没有 Linter 的时候盲目省略分号基本上就是作死（从不失手的肉体解释器除外）。 3. 如果是多人协作的项目，要以团队为重，个人让步，Leader 负责把控标准对于项目整体和未来发展的适用性。只要没有明显的风险其实都可以尝试接受。 4. 能用工具限制的事情，尽量不要靠自觉。一来可以使得团队和睦，免去扯皮；二来可以提高效率。各自语言的 Linter 、.gitignore 、editorconfig 、commitlint 再说说管理上的，个人建议就事论事，有问题解决问题，没必要带入情绪（当然做到这个很难）。 其实通常出现情绪主要还是因为举手无措，由一个问题反复解决但是最终仍然复发而导致的懊恼；可以尝试加一些轻的奖惩机制，比如 6 人的团队，谁出现一次不符合标准的情况就请大家伙下午茶，这样惩罚不重，但也始终有个惩罚在那时刻提醒大家要遵循标准。 |
|
59
libook 2020-07-01 10:48:39 +08:00
补充一点：
5. 没有什么是一成不变的，随着业务、技术、团队情况等等的变迁，标准可能需要修订。标准一旦实施就得 100%遵守，但是允许对标准有疑议，对新人来说可以出个标准的 FAQ，对老人来说随时可以拉会重新讨论标准。 |
 |
60
dearmymy 2020-07-01 11:11:57 +08:00
没有被加班，通宵赶进度毒打过么。。。
|
|
61
loliordie OP @dearmymy 一般项目我会给团队争取 10%-20%的缓冲时间 这个是硬条件我从来没妥协 大 BOSS 也知道我的团队不怎么出错 容许这个行为 另外我也尽量减少开会这种浪费时间的行为 所以一般我们都会有比较充裕的时间来改改代码整理一下文档
|
 |
62
zjsxwc 2020-07-01 11:35:19 +08:00
看公司，以前上上家公司，写烂代码（随意命名）会被开会批斗，因为 40 多人维护一套代码，还有开源版本的二开，之后几家内部系统就几个人自己万就比较随意了，逃
|
 |
63
zhuangzhuang1988 2020-07-01 11:44:52 +08:00
不是.
|
 |
64
cweijan 2020-07-01 11:49:30 +08:00
git add * 这语句没有任何问题, git 项目应当在 gitignore 过滤临时文件,
至于代码洁癖, 当然是好事, 但你需要为你的规范定一个标准明确告知. |
 |
65
Acoolda 2020-07-01 12:24:23 +08:00 via Android
你自己严格要求自己没啥问题，但是同事之间，应该设定一个最低标准(不影响项目进度)。每个人都有自己的习惯，没必要干涉。
|
 |
66
sockpuppet9527 2020-07-01 12:31:32 +08:00
看到楼上已经有老哥提及了 hook + ci 了
我个人还是非常方案这种又拿洁癖说事，又不加上这些工具的人的。 |
|
67
sockpuppet9527 2020-07-01 12:31:50 +08:00
@sockpuppet9527 #66 方案 -> 反感
|
 |
68
cnbattle 2020-07-01 12:36:01 +08:00
普及一下 git 相关知识点，写入规范文档不就好了
为什么要用最坏的方式处理，发现问题要先想怎么处理及避免，而不是生气批评，弄得大家都不舒服 0.0 |
 |
69
yuchenyang1994 2020-07-01 12:42:40 +08:00
1. 无论什么东西，一旦过于偏执就不是好事
2. 干的就是脏活，代码不可能干净 3. 适当留一点脏代码，给实习生练手，不是核心业务不挣钱的业务给他们做，让他们慢慢理解脏代码为什么脏，但你发火，一解决不了问题，二，大家都不舒服。当然看到不爽在这吐槽没啥问题 |
 |
70
liuqiang1357 2020-07-01 12:48:33 +08:00 via Android
git add .不香吗，整个图像化工具，提交前还能 review 一下，不能放到 ignore 里面，具体啥原因能说一说吗
|
 |
71
Tenlp 2020-07-01 12:51:06 +08:00 via Android
有必要，代码整洁性应该是从入门编程就该一直注意的一点，不过很多大学或者培训机构反倒忽视了这一点
|
 |
72
qiumaoyuan 2020-07-01 12:51:18 +08:00
哈哈哈加油
|
 |
73
hallDrawnel 2020-07-01 12:52:32 +08:00
我的建议是不要手动去做这些工作，通过 CI 、IDE 插件、统一配置、文档来控制，合并代码不过 CI 不合并，这样避免你直接和合并代码的人冲突。从技术上杜绝不符合你的要求的代码合并到主干，规则都写清楚，这样谁不遵守那就是谁的锅了， 不让他合并理由也十分充分。
发现漏网之鱼补上规则检查就好。这些例子就可以整理一个文档贴出来，周围人犯的错有很好示范作用。 都是来搬砖的，好好说话别发火。人家实习生跑了，回学校一说，可能这个学校的人都主动避开你这个部门了。 |
|
74
qiumaoyuan 2020-07-01 12:53:41 +08:00
代码统一风格仅仅是树立权威而已，没别的用处。
代码的可读性来自于命名、DRY，没了。当然，多数人不这么认为。 |
 |
75
ai277014717 2020-07-01 13:03:49 +08:00
站在填坑人的角度考虑应该是好事
|
 |
76
ruyu 2020-07-01 13:14:35 +08:00
我也有点代码洁癖. 但是我慢慢发现, 编程是一件理性的事, 但是 "洁癖" 太感性了.
|
 |
77
1109599636 2020-07-01 13:16:25 +08:00
我觉得 任何强制性要求应该有基础设置作保证，
比如代码格式 可以用 pre-commit hook 在 git 提交代码的时候验证格式，不符合不能 commit，自然也不能 push，有的语言还可以自动格式化。 这样比人为操作不仅方便还更高效。 |
|
78
1109599636 2020-07-01 13:17:34 +08:00
|
 |
79
Mark24 2020-07-01 13:23:22 +08:00
你应该用 lint 、commit hook 、gitignore 去约束。
而不是要教导每一个人。那样没意义呀。 |
 |
80
love 2020-07-01 13:48:31 +08:00
是好事，除非水平跟不上眼界的时候还硬要跟，眼界都是大于实际水平，做好平衡就可。
|
 |
81
yolee599 2020-07-01 14:14:59 +08:00
代码洁癖是好事
|
 |
82
yuankui 2020-07-01 14:31:28 +08:00
怎么都好，发飙不好
|
 |
83
thulof 2020-07-01 14:47:39 +08:00
实习生提 MR 之前自己不看 diff 吗……
|
 |
84
WytheHuang 2020-07-01 14:55:25 +08:00
@ericls #15 中肯
|
 |
85
charlie21 2020-07-01 15:00:51 +08:00
扣钱阿？
|
 |
86
yaphets666 2020-07-01 15:03:47 +08:00
我工作两年多了,除了技术我觉得我最有收获的就是深刻的认识到了工作绝对不带情绪.
|
 |
87
notejava 2020-07-01 15:30:49 +08:00
对自己的代码洁癖，别人的代码随意。
|
 |
88
HenryWang0723 2020-07-01 15:35:21 +08:00
如果你是实权领导，可以理解，不合适就辞退。如果不是，你的行为接近于癖了，显然这个词不是个好的意思。除了制造矛盾让别人不爽外，你自己不是也烦躁了吗。把情绪的精力放在从细节实际上培训和统一代码规范上，有意义得多
|
 |
89
fenyu 2020-07-01 17:36:02 +08:00
我吐槽一下，如果说洁癖我也有也很支持这么做
但是为什么不把那些加.gitignore， 如果你是实权或者负责 review 代码， 另外新人嘛，警告几次，拒绝几次就好 |
 |
90
miniwade514 2020-07-01 18:07:27 +08:00
代码规范是好事。但是沟通带情绪就不太好了，尤其是对下属。想想，如果是你的 leader 提交了不符合规范的代码，你会对他发火吗？离开这份工作，大家都是一样的普通人，对人 nice 一点，以后也许还能一起撸个串。
|
 |
91
salmon5 2020-07-01 18:16:31 +08:00
@miniwade514 如果“不符合规范的代码”，经常引起故障或者以后可能会引起故障，让你背锅呢？还能心平气和吗
|
 |
92
aguesuka 2020-07-01 18:48:27 +08:00
洁癖没问题，发火有。但是最大的问题是你没有意识到这一点
|
 |
93
blackshow 2020-07-01 18:55:40 +08:00
累
|
 |
94
cco 2020-07-01 18:57:23 +08:00
唉，一样的事，只不过不配合而已。
|
 |
95
d0wnl0ad 2020-07-01 19:09:12 +08:00
我觉得，这个更多是 SOP 的定义及流程落地的问题。
规范有白纸黑字写下来吗？有确保这个规范在入职培训里面吗？有确认培训的有效，到位吗？有设立奖励机制来确保大家有动机去做这个？系统有足够的防呆来抑制出错嘛？有强制执行规范的决心嘛？ 说真的，单靠宣导不一定能够达到目的，特别是无明显好处+增加工作量的事情。 必须有更多的制度去诱导这个行为。 |
 |
96
zypy333 2020-07-01 19:34:38 +08:00
我也有代码洁癖
同事们数据库建表,表名,大小写混着写,还有拼音首字母缩写当表名,横杠还有两个连到一起的 前台控制台里报不影响功能的错也不管,类名不写注释干啥用的 有同事还有写那种写死数据的假代码(原型产品,离上线测试还很远)... 太多了,我提醒了也不管用,不鸟我,私下估计不恨我都不错了 关键是这团队技术负责人,不做代码审查,之前定的规范也不管大家执行不,每个周末只看功能,界面看起来可以就能混过去 |
 |
98
chenyi 2020-07-01 20:00:59 +08:00
洁不洁癖不重要，反正我觉得代码风格统一挺重要的，而统一代码风格最好的方式就是用工具
|
 |
99
gunavy 2020-07-01 20:07:42 +08:00
嗯……
如果你是大哥，是个好事。 如果你不是大哥，降低了你的不可替代性？，（逃 |
 |
100
octalempyrean 2020-07-01 21:43:57 +08:00 via Android
视情况而定吧
|
Select Language