[TL]分享一下我的偏执
jun lin
我有种偏执，在程序开发的时候，总会想办法把所有事情抽象化，
本来界面编程拖拉控件就可以的，我偏要自己先整理出界面上需要完成的功能，
然后用个函数自动生成界面，或者直接手写代码。
本来一个功能可以放在一个文件里面的，我却会根据功能，UI，数据库操作，常用的方法给分离成许许多多的文件，
甚至还有一个makefile来执行测试，生成安装文件。
本来可以用MFC直接做开发的，我却因为生成的代码太恶心不够模块化，而转而选择不容易把握性能的python+qt。
本来我可以直接调用MFC的串口通讯函数的，我却因为偷懒转而使用速度慢的pyserial。
本来代码可以开发完毕的，我还要一遍遍地回头修改，不好看的地方要么包到函数里面，要么加上大堆的注释，直到没有什么一眼看上去不对劲或者不能理解的程度。
大家有什么偏执，一起分享吧。
Jeff Chen
--
My Blog：http://jeffchen.cn
sagasw
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
Poople
一个问题的各种设计都会有某方面的好坏（可能是扩展性和易于实现性或者其他方面的指标），
而好的设计就是能在设计之初就看到这些不同点，从而找到最佳的平衡点；（可能是从扩展性和易于实现或者性能的方面的一个平衡）
如果一味的寻求所谓的最好的设计（其实我认为是不可能存在的），那只能说是过度设计了，忘记了程序设计的根本目标！
On 12月11日, 下午1时32分, Jeff Chen <sheismyl...@gmail.com> wrote:
> 我经常会想出很多变态的情况，来测试自己的solution.
>
> 想得越多，越觉得不够，生怕什么特殊情况没有考虑到 ：（
>
> 2009/12/11 jun lin <linjunhal...@gmail.com>
jinhu wang
Poople
我觉得编程中的“偏执”是一种习惯。写程序很大程度上是一个严谨的东西，你不小心留下的任何一个陷阱都可能会成为将来的一个灾难，所以偏执一点没坏
处。
我记得高中的时候做题，计算完结果，我总会再用另一种方式验证一遍，这就是迭代吧。
非常同意这个观点！应该来说写程序是一个绝对严谨的东西，但要分偏执的是哪个方面，对逻辑的偏执是绝对要支持的；
但看1楼和2楼的很多偏执，看起来和你说的偏执是不同类型的偏执！
On 12月11日, 下午2时10分, jinhu wang <wangjinhu...@gmail.com> wrote:
> 我觉得编程中的“偏执”是一种习惯。写程序很大程度上是一个严谨的东西，你不小心留下的任何一个陷阱都可能会成为将来的一个灾难，所以偏执一点没坏处。
> 我记得高中的时候做题，计算完结果，我总会再用另一种方式验证一遍，这就是迭代吧。
>
> 2009/12/11 Poople <pooples...@gmail.com>
>
>
>
> > 不分享偏执了，先泼泼冷水 ：）
>
> > 一个问题的各种设计都会有某方面的好坏（可能是扩展性和易于实现性或者其他方面的指标），
> > 而好的设计就是能在设计之初就看到这些不同点，从而找到最佳的平衡点；（可能是从扩展性和易于实现或者性能的方面的一个平衡）
>
> > 如果一味的寻求所谓的最好的设计（其实我认为是不可能存在的），那只能说是过度设计了，忘记了程序设计的根本目标！
>
> > On 12月11日, 下午1时32分, Jeff Chen <sheismyl...@gmail.com> wrote:
> > > 我经常会想出很多变态的情况，来测试自己的solution.
>
> > > 想得越多，越觉得不够，生怕什么特殊情况没有考虑到 ：（
>
> > > 2009/12/11 jun lin <linjunhal...@gmail.com>
>
> > > > dear all forks:
> > > > 我有种偏执，在程序开发的时候，总会想办法把所有事情抽象化，
> > > > 本来界面编程拖拉控件就可以的，我偏要自己先整理出界面上需要完成的功能，
> > > > 然后用个函数自动生成界面，或者直接手写代码。
> > > > 本来一个功能可以放在一个文件里面的，我却会根据功能，UI，数据库操作，常用的方法给分离成许许多多的文件，
> > > > 甚至还有一个makefile来执行测试，生成安装文件。
> > > > 本来可以用MFC直接做开发的，我却因为生成的代码太恶心不够模块化，而转而选择不容易把握性能的python+qt。
> > > > 本来我可以直接调用MFC的串口通讯函数的，我却因为偷懒转而使用速度慢的pyserial。
>
> > 本来代码可以开发完毕的，我还要一遍遍地回头修改，不好看的地方要么包到函数里面，要么加上大堆的注释，直到没有什么一眼看上去不对劲或者不能理解的程度。
>
> > > > 大家有什么偏执，一起分享吧。
>
> > > --
> > > My Blog：http://jeffchen.cn- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Nan Hu
http://groups.google.com/group/zeeslo/
hu
可以考虑心理咨询一下。
郑培祥
--
此致
敬礼！
郑培祥
--
Zheng PeiXiang
C++, JAVA, PYTHON, NLP, Semantic Role Labeling
woo
如果碰到一个同样偏执的项目经理，
偏执的要求你在两周之类给出可用的产品
偏执的要求你用保守的方式进行开发
偏执的要求你的工作能够简单的被同事(不会写makefile）接管，让你去做其他的项目
你怎么搞
再说了，看你写了这么多，我有一个疑问,你的文档跟你的代码差距有多大？
ZhiGang Qi
第二， 我很讨厌的一种代码风格就是a=1... in sin.
a = 1 or a == 1 多好啊。。。。
--
Zhigang Qi
345 park ave, W12-302
San Jose , CA 95110, USA
Cell: (812)272-1809
work: 408-536-247
Fuzhou Chen
这也是另一种偏执吧。:)
我的偏执似乎和流行的正相反：我就见不得没用的code留在项目里。要
是什么函数或类已经不需要了我就要求把它们清除出代码，代码里没有
被立即用上的接口也最好去掉。为这毛病在公司内外还得罪了不少人，
可就是改不掉。
2009/12/11 ZhiGang Qi <zhiga...@gmail.com>:
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
jun lin
2周之内：我会裁剪需求。
保守：我会开发2份代码。
接管：makefile和VC之类同时使用
文档：经常被强迫review，已经非常熟练于写文档。
limodou
> 我对程序当中的空格非常非常的偏执......
> 比如 a = 1,我就浑身不舒服,非要改成a=1.
> 每次用别人的代码,都要花几个小时把空格去掉.>_<
我晕，我和你正好相反。在我所写的python代码中，我都要在操作符前后加上空格，看上去更清晰。只不过如果别人的代码不是我也未必会改，没你这么“厉害”。
--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou
limodou
> 在我们公司写a=1在review的时候会被一群人指摘你为啥不写 a = 1，
> 这也是另一种偏执吧。:)
>
> 我的偏执似乎和流行的正相反：我就见不得没用的code留在项目里。要
> 是什么函数或类已经不需要了我就要求把它们清除出代码，代码里没有
> 被立即用上的接口也最好去掉。为这毛病在公司内外还得罪了不少人，
> 可就是改不掉。
>
干净有干净的好处，但是留下痕迹也有助于别人理解代码变化的过程。各有利弊。只要不是“过尤不及”就好。
madongfly
On 12月11日, 下午1时56分, Nan Hu <hunan1...@gmail.com> wrote:
> 我对程序当中的空格非常非常的偏执......
> 比如 a = 1,我就浑身不舒服,非要改成a=1.
> 每次用别人的代码,都要花几个小时把空格去掉.>_<
>
> 2009/12/11 sagasw <sag...@gmail.com>
>
> > 参考TBBT的主角，这是一种强迫症的表现。
>
> > ------------------------------------
> > C++, Lua, living in Dalian
> >http://sunxiunan.com/
> >http://twitter.com/sagasw
> > ------------------------------------
>
> > 2009/12/11 jun lin <linjunhal...@gmail.com>
Fuzhou Chen
我现在的看法是记录痕迹的任务我们早就已经交给版本管理工具了，为什么
非得要在代码里再留一份？而且如果某个函数因为版本变化而不再使用，那
么就说明其必定在某些地方有问题。要是将来开发人员换个新人，在不了解
历史的情况下看见这个函数就用，搞不好就要出错。所以不如趁早删掉干净。
退一步讲，就算是将来后悔了，从老版本里把函数重新拷贝回来，其实也不
费多少事情。所以也就一直没觉得自己错。
2009/12/11 limodou <lim...@gmail.com>:
--
Fei Yan
清楚垃圾代码对于一个老项目而言作用是非常显著的；这种偏执应该得到鼓励。。。
一年多以前我开始接受我们的代码的时候，看到几个函数的作用感觉稀里糊涂，加上很多函数指针的传递，一时半会儿倒也拿捏不准那段代码有没有人用
最后请教阿三师傅，对方花了一个多小时苦力后才告知我此段代码属于3年以前的实验性杰作，写好之后就没用过而是采用了另外的实现方法
还好那位老兄立刻就提交了SR，将他知道的无用代码给清理掉
还有一个例子是某次偏执的我将代码的-Wextra打开，将我能控制的代码里边的warning全修改掉，不过大家也都容忍了我
raymond
On Dec 11, 1:32 pm, Jeff Chen <sheismyl...@gmail.com> wrote:
> 我经常会想出很多变态的情况，来测试自己的solution.
>
> 想得越多，越觉得不够，生怕什么特殊情况没有考虑到 ：（
>
> 2009/12/11 jun lin <linjunhal...@gmail.com>
居振梁
1.为了能够自动化，我宁愿自己写参数文件（不是传统的配置文件）然后解析，也不用GUI工具来生成这些文件（比如Qt的ui和translation）。
2.为了让自己的代码看起来舒服，一切向着完美的修改都会不断进行，直到“没有”瑕疵。比如：一个局部变量的命名。
3.变量个数和代码行数（在不影响质量的前提下，我会向着尽量少的方向修改，哪怕将影响可读性的地方写到注释里去，如果你一定要看的话。空行不算）。可读性和代码量在我这绝对是一个难以权衡的问题。特别不喜欢看那些一上来就声明一砣变量，每个一行然后有些变量只作为中间变量只被用一次。
不过以上只适用于“私人代码”，如果我所在团队有规范，那就按那个规范来，“适应”是一种必备技能。
--
战斗暴龙：理论由自己理论，由这理论演绎实践；实践由自己实践，由这实践归纳理论。事事都理论+实践太累了。
http://wargrey.yo2.cn [黑客精神；团队精神；清心寡欲；像孩子一样思考]
http://wargrey.blogspot.com [BY-BLOG；自然语言试练场]
http://juzhenliang.blogspot.com [中文译出]
woo
这样的代价太大了。限于各种现实原因，比如开发应用，lincense啊，真正投入应用的只有一种了,你的工作被老板认可的也只有一种，当然，这话可能说的现实了点，其他的工作量，别人可能知道，也可能不以为然，因为大多数人只对自己看得到的东西感兴趣。
与其有这个时间，可以把真正用到的解决方案做好做完美
也可以去玩玩别的东西,比如pyQT什么的
ps:不知道你对于pypy有没有了解，这个据说性能已经非常好了
jun lin
SevenCat
On 12月12日, 上午2时51分, Fuzhou Chen <cppof...@gmail.com> wrote:
> 在我们公司写a=1在review的时候会被一群人指摘你为啥不写 a = 1，
> 这也是另一种偏执吧。:)
>
> 我的偏执似乎和流行的正相反：我就见不得没用的code留在项目里。要
> 是什么函数或类已经不需要了我就要求把它们清除出代码，代码里没有
> 被立即用上的接口也最好去掉。为这毛病在公司内外还得罪了不少人，
> 可就是改不掉。
>
> 2009/12/11 ZhiGang Qi <zhigang...@gmail.com>:
>
>
>
>
>
> > 第一，你不用手动的把空格去掉。。。 设置一下你自己的editor，然后reformat一下就可以了。
>
> > 第二， 我很讨厌的一种代码风格就是a=1... in sin.
>
> > a = 1 or a == 1 多好啊。。。。
>
> > 2009/12/10 Nan Hu <hunan1...@gmail.com>
>
> >> 我对程序当中的空格非常非常的偏执......
> >> 比如 a = 1,我就浑身不舒服,非要改成a=1.
> >> 每次用别人的代码,都要花几个小时把空格去掉.>_<
> >> 2009/12/11 sagasw <sag...@gmail.com>
>
> >>> 参考TBBT的主角，这是一种强迫症的表现。
>
> >>> ------------------------------------
> >>> C++, Lua, living in Dalian
> >>>http://sunxiunan.com/
> >>>http://twitter.com/sagasw
> >>> ------------------------------------
>
> >>> 2009/12/11 jun lin <linjunhal...@gmail.com>
jinhu wang
SevenCat
On 12月12日, 下午7时27分, jinhu wang <wangjinhu...@gmail.com> wrote:
> 你这个习惯估计是跟大多数人或大多数公司的编程习惯或者规范相背的。
>
> 2009/12/11 Nan Hu <hunan1...@gmail.com>
>
>
>
> > 我对程序当中的空格非常非常的偏执......
> > 比如 a = 1,我就浑身不舒服,非要改成a=1.
> > 每次用别人的代码,都要花几个小时把空格去掉.>_<
>
> > 2009/12/11 sagasw <sag...@gmail.com>
>
> > 参考TBBT的主角，这是一种强迫症的表现。
>
> >> ------------------------------------
> >> C++, Lua, living in Dalian
> >>http://sunxiunan.com/
> >>http://twitter.com/sagasw
> >> ------------------------------------
>
> >> 2009/12/11 jun lin <linjunhal...@gmail.com>
kid
jinhu wang
est
27149
On 12月11日, 下午1时56分, Nan Hu <hunan1...@gmail.com> wrote:
> 我对程序当中的空格非常非常的偏执......
> 比如 a = 1,我就浑身不舒服,非要改成a=1.
> 每次用别人的代码,都要花几个小时把空格去掉.>_<
>
> 2009/12/11 sagasw <sag...@gmail.com>
>
>
>
> > 参考TBBT的主角，这是一种强迫症的表现。
>
> > ------------------------------------
> > C++, Lua, living in Dalian
> >http://sunxiunan.com/
> >http://twitter.com/sagasw
> > ------------------------------------
>
> > 2009/12/11 jun lin <linjunhal...@gmail.com>
wang carl
Nan Hu
Fuzhou Chen
也就是大家都接受了这个习惯以后直接写进了编程规范，彼此适
应一下就好了。
2009/12/11 Nan Hu <huna...@gmail.com>:
--
Fei Yan
不过我比较讨厌一大堆的变量赋值放在一块，C却是鼓励这个的，可能因为早期K&R只支持变量在函数开头处声明的缘故
stefan
jun lin
Roof
张慧聪
我觉得要看实际效果，比如我在洗菜的时候总是想一片叶子也不丢，哪怕是很小的一片小叶子，吃饭的时候我总是一粒米也不剩，切蒜苔的时候我总是想切得一样长……
其实有的时候是很浪费时间的，我就默念"There's no perfect"来提醒自己。
空不空格最终还是要好看清楚，其实逻辑清晰的代码，只要缩进好了就都可以看，我是看K&R的书学的，所以最习惯那样的代码风格，但要是有把{写在行首的其实习惯一下就好了。
花太多时间在这种小地方上不值得
--
----文艺型程序员+围棋偶饭+SC剩菜饭+前科幻迷+数学习饭
黄冠
HUA
--
成大事者，在孤独中享受寂寞，从寂寞中厮杀黎明！
好好学习，天天向上！
Jonathan Swift - "May you live every day of your life."
jinhu wang
Zhiming G
Zhiming G
Fuzhou Chen
常常就可能靠这个发现。所以这样的偏执需要大力提倡，呵呵。
2009/12/15 Zhiming G <gao...@gmail.com>:
--
sagasw
我们以前的项目（不是我接手过的），如果警告开到4，能发现一大堆问题，
主要是参数未使用或者定义了变量不使用之类，偶尔也能发现一些不常见的错误。
不过像是new []但是没有delete []的问题就只能眼睛看，至少vc编译器是不行的。
btw，如果vc编译器能检查出类似“嵌套层次过多”“函数过长”之类的问题就更帅了。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
HUA
int f(){
}
....:(
jun lin
OxFAN
居振梁
就是说只要一个变量有“命名作用域”就一定要把它写完整了。
比如不辞辛苦的一遍又一遍的在membervar前写"this."，
这样的好处是
1.让编译器一看就知道要引用那个变量；
2.方便批量重命名而不会与局部变量冲突；
3.在我这this是彩色高亮的，看起来比较舒服。
缺点是：
1.大大扩展了一个复杂表达式的长度使得整体看起来不舒服；
2.将一段正常代码复制到另一个闭包函数里会引起混乱；
3.好像是有点罗嗦，呵呵。
--
战斗暴龙：理论由自己理论，由这理论演绎实践；实践由自己实践，由这实践归纳理论。事事都理论+实践太累了。
http://wargrey.yo2.cn [黑客精神；团队精神；清心寡欲；像孩子一样思考]
http://wargrey.blogspot.com [BY-BLOG；自然语言试练场]
http://juzhenliang.blogspot.com [中文译出]
jun lin
up duan
有人有this癖吗？
就是说只要一个变量有“命名作用域”就一定要把它写完整了。
比如不辞辛苦的一遍又一遍的在membervar前写"this."，
这样的好处是
1.让编译器一看就知道要引用那个变量；
2.方便批量重命名而不会与局部变量冲突；
3.在我这this是彩色高亮的，看起来比较舒服。
缺点是：
1.大大扩展了一个复杂表达式的长度使得整体看起来不舒服；
2.将一段正常代码复制到另一个闭包函数里会引起混乱；
3.好像是有点罗嗦，呵呵。
可维护性差主要体现在如果你调整了类所处的包，或者改变了使用的类，用了另一个包中同样功能的类，结果导致你处处改动。而实际上，如果不用作用域复合指定类的话，这个改动本不该引起这么多麻烦的。
另一个缺点就是它有西方语言的倾向：不考虑上下文也是可以理解的。之所以这个被认为是一个缺点，是因为我们习惯于在一定的Context下表述问题，而不是时时刻刻的处在无场景中表述问题，那样会导致理解上的复杂。
SpitFire
Zane Zheng
陆军军
{
for (int i = 0; i < 10; ++i) {
// xxx
}
}
习惯在定义时用
xxx
{
}
在循环等用
xxx {
}
居振梁
类似的问题还有一个，以前在用c/c++时一直坚持“能用指针的地方一律只用指针”，其实栈对象和堆对象各有优劣。
向着类“似情况而定”的癖最好还是不要理智一点比较好。
所有的命名作用域都有一个最大的缺点，可维护性差。
可维护性差主要体现在如果你调整了类所处的包，或者改变了使用的类，用了另一个包中同样功能的类，结果导致你处处改动。而实际上，如果不用作用域复合指定类的话，这个改动本不该引起这么多麻烦的。
另一个缺点就是它有西方语言的倾向：不考虑上下文也是可以理解的。之所以这个被认为是一个缺点，是因为我们习惯于在一定的Context下表述问题，而不是时时刻刻的处在无场景中表述问题，那样会导致理解上的复杂。
居振梁
两外对于可维护性差的那个缺点不是很理解，对于一个给定的变量，其类型已经确定了吧，即使包换了，也只是在申明该变量时有可能需要更改？
声明时坚持指定作用域复合的"层次"或者选择不同的“root起点”来如何呢?类似简单类名和全限定类名的区别。