1
johnnie502 2017-01-13 15:45:06 +08:00 1
挺好,公司以后的 code review 就全拜托你了
|
2
shoaly 2017-01-13 15:46:24 +08:00
希望你终究会变成 只见森林不见树木.
森林 = 接口和框架结构 树木 = 函数 |
3
murmur 2017-01-13 15:46:36 +08:00 1
做程序员大忌就是随便格式化别人的代码
|
4
linbiaye 2017-01-13 15:48:51 +08:00 1
就算是烂代码也跑成了稳定的烂代码。没事别乱动,否则你那是闷声作大死。
|
7
falcon05 2017-01-13 16:32:48 +08:00 via iPhone 1
体验是加班更多了,因为总想写得更好
|
8
orderc 2017-01-13 16:38:27 +08:00
头发白了,驼背了,眼睛花了
|
9
xujinkai 2017-01-13 16:38:52 +08:00 via Android
我还在学习中。别说别人的代码,看见自己几个月前的代码都没法忍
|
10
lrh3321 2017-01-13 16:46:24 +08:00
能正常运行的代码就是好代码。
写好测试,反正有 VCS ,改完还能通过就行,不行就回退回去。 |
11
xbdsky 2017-01-13 16:50:44 +08:00 1
有这种感觉,看到乱七八糟的代码就喜欢手贱给格式化下,看上面大神这么说,下次不敢随便乱动了,哈哈, 233
|
12
Phariel 2017-01-13 17:05:10 +08:00 via Android
不要改 改了总有一天你会付出代价
_(:3)∠*)_ |
13
cleveryun 2017-01-13 18:40:44 +08:00 via iPhone
看到一个文件有多种缩进方式的会去手动修改,看到代码冗余太多的会去改,看到可读性差的代码会去改变量名或者加备注,上班无聊的时候会去审查代码。
现在好很多了,除非能预期到有很多很多的空闲时间,否则不会打算去把整个项目重构掉,因为脑子单线程,比起手贱更讨厌写一半放那里的感觉,另一方面,项目也越来越大了。 |
14
lizon 2017-01-13 18:46:38 +08:00
别改
有必要的话自己写个中间层,把自己的代码和别人的代码隔离,你自己的代码想怎么改就怎么改 |
15
lslqtz 2017-01-13 18:47:36 +08:00
自己写的代码好就行,别管别人的代码。
|
16
blackjar 2017-01-13 18:58:56 +08:00
给个 git 。我一直想看看强迫症写的代码
|
17
XhstormR 2017-01-13 19:40:43 +08:00 via Android
|
18
shijingshijing 2017-01-13 19:51:07 +08:00
我就很喜欢和强迫症一起合作啊,我自己也是强迫症啊,哈哈~~~
|
19
cuebyte 2017-01-13 19:55:17 +08:00
@shijingshijing 如果编码风格不一样的话就不愉快了
|
20
shijingshijing 2017-01-13 20:13:16 +08:00
@cuebyte 是的,最要命的就是{},我喜欢
Func () { } 因为这样占用空间小,碰到一个喜欢 Func() { } 这样的,然后就进入了死循环模式,还好有 vim ,我一上来直接 gg=G ,然后等我改完 commit 之后,脑补他打开的样子,一本满足~~~ 哈哈 |
22
youyi OP @shijingshijing 知己啊,哈哈
|
23
kimwang 2017-01-13 20:23:43 +08:00 3
我很喜欢看倪匡的访谈,感觉对于治疗强迫症是非常的有效。
倪匡写小说从来不修改(他破吉尼斯世界纪录的写作量理论上也不允许太多修改),以至于他的长期读者可以从中找到非常多的“纰漏”,他却很坦然,错误必须存在,况且写小说,体裁上本来就是虚构的成分为主,别人疑问南极怎么会有大白熊?他说我喜欢大白熊,所以大白熊就在小说里出现了,至于在南极还是北极?在南极也没问题啊,又不是地理杂志。台湾也有不少修正他小说情节和续写的版本,也同样受欢迎,看看你想做倪匡还是做修订版作者吧~ 还有个日本的摄影师荒木静惟,宝丽来作品都可以办摄影展,有些作品的构图、用光简直可以用“一塌糊涂”来形容,用严肃摄影的眼光来看简直不可理喻,如果强迫症,这怎么可以办得到?他用手动相机时,过片与按下快门之间几乎为零的时间间隙,在我看来根本就不存在思考的,所有我又去看了透露荒木经惟心路历程的图书(自传)。 最终,我发现那些功成名就的脑力劳动者,通常很高产,高产可以解决很多问题,他让你有足够的作品用来总结、自省,同时又能充分消耗掉你的创作时间,你没有时间去否定自己,比如我是否该停下来先解决不够完美的问题?答案是不必。 总的来说,他们不是拿时间来总结,是拿行动结果来总结,别人拿来总结的时间,他们仍然用来进行创作。而他们对于自己作品的不足,有足够的坦诚(黑体加粗)来面对,对于自己的作品尚且如此,更何况别人?所以倪匡是一个非常崇尚个体自由,并且尊重别人自由的人。 现在我很少希望去改变别人,我只希望自己能够坦诚(黑体加粗),这很重要,特别对于疑似强迫症患者。 |
24
zingl 2017-01-14 00:04:52 +08:00
“萝卜快了不洗泥”原来可以有如此高大上而又清新脱俗的表达方式
|
25
bk201 2017-01-14 01:45:08 +08:00 via iPhone
最讨厌这种人,自以为是.别人的代码要你改什么,出错了你负责吗?有 BUG 了算谁的.
|
26
t6attack 2017-01-14 01:48:01 +08:00
完美主义 + 强迫症 + 拖延症 = 一事无成的废物
|
27
scnace 2017-01-14 02:28:11 +08:00 via Android
少年 我给你指条明路:处女座程序猿就应该学 Golang(笑
|
28
loading 2017-01-14 08:04:52 +08:00 via Android
老板:老李,你过来,你开发的服务出问题了!
楼主:呵呵,老李完蛋了。 老李:老板,上次楼主改过我代码,是他弄的。 老板:哦,叫他加班修好就别来上班了,估计挺累的。哦,是以后都不用来上班了! 楼主:…… |
29
depress 2017-01-14 09:20:07 +08:00
我就是,强迫症很严重,对代码的完善程度和格式有很高要求,我的代码基本不用测试也无 bug 就是因为写的时候考虑的很周全,项目组的代码规范和 code review 我也是唯一一个作为普通员工参与的,但是因为经理也不在乎这个,提出问题同事也都不会改,所以项目的代码乱七八糟的,但测试也都能过,各种打补丁的方式修 bug 。这也就是我决定离职的原因,好好的一个规整的项目从 0 开始变成了现在这模样。不过哪怕别人代码再差也一动不要动,不动出问题都是别人的,你就减个空行那出问题都是你的,避免给自己揽事。
其实作为程序员,先解决有没有,再解决好不好,是对的,因为大家拼的都是速度,晚一步市场就被别人占了。不过于我而言,我无法做到这样,除非我做到决策层,不用审阅代码了,那可以。毕竟强迫症不好改。所以能遇到一家大部分人都有代码洁癖的公司真的是我的幸运吧。 |
30
daysv 2017-01-14 09:47:07 +08:00
i dont care
就是改 |
31
murmur 2017-01-14 10:28:43 +08:00
代码风格什么的只要大家都用一套,就可以,哪管再烂的风格只要大家一起用都出奇迹,何况很多时候开发都是一个人写模板其他人抄
我要求的就一点,英文标点符号后面空格,这是英语的语法 其余的,什么括号有没有空格,等号都没有空格,大括号有没有空格,问题不大,都是 IDE 还在乎这点 有的项目是 php 后端,那前端就走 c 风格,用小写下划线分割 有的项目是 java 后端,那前端就 java 风格走驼峰命名 这点应变能力都没有就别写代码了 |
32
HuangLibo 2017-01-14 10:45:30 +08:00
强迫症怎么不写注释, 看来你病的还不严重
|
33
eslizn 2017-01-14 11:04:44 +08:00
我觉得 go 这一点做的不错,格式已经订好了,看你们能乱成什么样
|
34
ayiis 2017-01-14 11:35:11 +08:00
上次有个强迫症在发布的时候把 sql 格式化了一下
`select sum(*) as count` 格式化之后变成 `SELECT SUM(*) AS COUNT` |
35
AlisaDestiny 2017-01-14 11:43:43 +08:00 via iPhone
@XhstormR .kt 是什么语法?导的是 Java 的包,语法却和 Java 有些出入。
|
36
XhstormR 2017-01-14 11:47:44 +08:00 via Android
@AlisaDestiny kotlin JVM 语言。
|
37
thinkif 2017-01-14 12:03:37 +08:00 via iPhone
真正的强迫症程序员应该是反复起来洗手,坐下擦键盘,擦显示屏,系统文件一有问题直接重置系统,桌面图标必须按照颜色排列,程序变量起名必须有规则等等,这才是强迫症
|
38
lizhenda 2017-01-14 12:17:34 +08:00
强迫症要么当老大,规则你定,要么啥都不说管好自己就可以了
|
39
shijingshijing 2017-01-14 12:17:56 +08:00
@thinkif 又被你说中了。。。 我一天洗手 20 多次,基本上只要感觉手上稍微有点汗(只是感觉),就会跑去洗一次。。。严重的时候一天洗过 30 多次,冬天好点。。。 一个月一瓶洗手液,后来实在受不了洗手液洗完后滑溜溜的(感觉有洗手液残留),全部换香皂了,双十一囤了好多香皂。。。。
|
40
shijingshijing 2017-01-14 12:21:46 +08:00
@murmur 我擦,最不能忍每行后面跟个空格啊,特别是类 C 的语言,每行后面有空格感觉就跟尿尿没尿干净一样,我只要发现代码有一个地方出现这种情况,必%s/\s\+$//全部给干掉。
最喜欢 VBA 里面写完一行回车立马自动给你格式化,等号两边自动加上空格( VBA 默认的。。。)。 |
41
danmary61 2017-01-14 13:13:24 +08:00
要学会接受这个世界的不完美,你才能感觉到快乐和幸福
|
42
kankana 2017-01-14 14:33:27 +08:00 via iPhone
原来是说代码风格……
|
43
zhang1215 2017-01-14 14:45:56 +08:00
不能忍受回收站里有东西
|
44
zoffy 2017-01-14 15:05:42 +08:00 via Android
this is society, mate
|
45
onesecure 2017-01-14 15:22:28 +08:00 via iPad
如果你没有足够强大的确信,不要轻易动别人的代码。否则你会死得很难看。老司机忠告。真的。
|
46
mazyi 2017-01-14 15:28:12 +08:00
这种强迫症只能打个引号了,遇到复杂的场景实现需求还来不及,还管长得漂不漂亮?
想要好看可以写 python 嘛。 |
47
neoblackcap 2017-01-14 15:32:30 +08:00
@murmur 公司的产品大忌就是,这个代码是某人的代码,那个代码是那人的代码,大家都只能维护自己的代码
|
48
leaybc 2017-01-14 16:40:11 +08:00
如果你又更好的方法,去改进别人的代码,并且提醒一下当事人,双方都有改进当然更好。
但是如果你不能明确的知道这段代码是干啥的,尤其是那些很老的代码,建议还是不要乱动的好。 |
49
murmur 2017-01-14 17:30:00 +08:00
@neoblackcap 不会的,只要第一个人写出模板,大家都是复制粘贴一个风格,至于维护性,这个必须要定期代码审查
怕就怕一知半解的程序员,太菜的什么也不会只敢复制粘贴,太牛逼的知道软件工程不呼呼乱来,那种一知半解的,学一点东西就敢魔改框架的,才是可怕 |
50
neoblackcap 2017-01-14 17:36:36 +08:00
确实第三种太 TM 可怕了,只能用单元测试来杜绝这样的人
|
51
xpol 2017-01-15 10:02:43 +08:00 via iPhone
这算啥,目前手上一个二手项目。其中一个类 96 个成员变量 6 个全局变量。 cpp 6 千多行。没测试。到处都是超长函数。
我也是活不下去的节奏了。 |
52
isPythoner 2017-01-15 15:02:54 +08:00
一步一格式化、保存,一次还不放心、必须多来几次,看到别人代码老想改
|
53
shijingshijing 2017-01-15 16:28:13 +08:00
@mazyi 强迫症表示最讨厌 python ,结尾不用个分号很难受,编码时为了提高目视效率,会把很多有规律的较短的代码放在同一行上,然后用 Tab 分开, Python 完全没办法用这种方式愉快玩耍。
|
54
mazyi 2017-01-16 17:58:44 +08:00
@shijingshijing 有规律的较短的代码应该成为函数,不应该放在同一行,这样不仅不能提高目视效率,还会增加他人阅读代码的难度。
|
55
shijingshijing 2017-01-16 18:32:25 +08:00
@mazyi 道理是这样的,可是我碰到的很多项目反而喜欢不封装,一个是函数跳转,出栈入栈会增加额外开销,当然你可以说写成 inline 类型,偏偏有很多不支持 inline ;第二很多 time critical 的系统,连短一点的,或者可以 predictable 的循环都做 unrolling ,所以这个也不是绝对的,即使封装成函数,也会把多行放在一行上的,做 code review 的时候,都还是要看的。
|
56
mazyi 2017-01-16 19:08:56 +08:00
@shijingshijing 只讲道理嘛,最佳实践的 trick 太多了。不过 review 的时候多行的意思应该更加明确吧。
|