h**i 发帖数: 712 | |
a*w 发帖数: 4495 | 2 我念本科时写过3000行的,用Turbo C 2.0搞的。
【在 h**i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 有人写了7000行
|
g*****g 发帖数: 34805 | 3 No function should be beyond 500 lines. Actually I can't
tolerate function longer than 200 lines.
【在 h**i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 有人写了7000行
|
l********a 发帖数: 1154 | |
g**e 发帖数: 6127 | 5 函数太多读起来也累,跳来跳去
【在 l********a 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 超过200行我就要切成函数了
|
a****l 发帖数: 8211 | 6 if someone did before, this person might be ashamed to tell the truth. If
this person did tell the truth, this person will feel ashamed afterwards.
【在 h**i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 有人写了7000行
|
S**I 发帖数: 15689 | 7 I once wrote a function with 5,000 lines when I was young, kind of ashamed
afterwards. :)
【在 a****l 的大作中提到】![](/moin_static193/solenoid/img/up.png) : if someone did before, this person might be ashamed to tell the truth. If : this person did tell the truth, this person will feel ashamed afterwards.
|
z****e 发帖数: 54598 | |
d***q 发帖数: 1119 | 9 3年前 维护过一个程序,主程序一个函数有13000 行代码。 |
f*****Q 发帖数: 1912 | 10 设计不够缜密的表现。
【在 g**e 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 函数太多读起来也累,跳来跳去
|
|
|
r*********r 发帖数: 3195 | 11 less than 80 chars wide, less than 100 lines tall.
less than 3 nested explicit loops. that's my rule. |
h********n 发帖数: 1671 | 12 这个问题不同时代的原则是不一样的。过去曾经鼓励写超长函数,因为那时编译器的
inline做得不好,都塞进一个函数里运行比较快。后来又有提倡写成宏定义来减小函数
长度,提高可读性,但是把宏当函数用,副作用比较多。还曾经有过一个原则是每个函
数不超过一页打印纸的长度,因为过去显示器和编辑软件都不行,经常需要把程序打印
出来阅读,超过一页打印纸的话,控制结构就看不清楚了。现在这些原则所依据的条件
都不存在了。
短函数也有时代局限。C++引入了functor的概念,带来了一堆琐碎的小函数,很讨厌。
C++0x引入了lambda,实际上是鼓励把函数写得稍微长一些,把引用的部分尽量塞进一
个函数体内。表面上看有点类似回到过去的原则,但是出发点是完全不同的。
无论长函数还是短函数,重要的是符合时代的特点。只要是根据当时软硬件条件制定的
原则,都是合适的。相反,时代变了,条件变了,还恪守过去的“原则”,就不合适了
。 |
g*****g 发帖数: 34805 | 13 It's not about long or short, but about readability which is almost
equivalent to quality for an application maintained overtime.
【在 h********n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个问题不同时代的原则是不一样的。过去曾经鼓励写超长函数,因为那时编译器的 : inline做得不好,都塞进一个函数里运行比较快。后来又有提倡写成宏定义来减小函数 : 长度,提高可读性,但是把宏当函数用,副作用比较多。还曾经有过一个原则是每个函 : 数不超过一页打印纸的长度,因为过去显示器和编辑软件都不行,经常需要把程序打印 : 出来阅读,超过一页打印纸的话,控制结构就看不清楚了。现在这些原则所依据的条件 : 都不存在了。 : 短函数也有时代局限。C++引入了functor的概念,带来了一堆琐碎的小函数,很讨厌。 : C++0x引入了lambda,实际上是鼓励把函数写得稍微长一些,把引用的部分尽量塞进一 : 个函数体内。表面上看有点类似回到过去的原则,但是出发点是完全不同的。 : 无论长函数还是短函数,重要的是符合时代的特点。只要是根据当时软硬件条件制定的
|
r*********r 发帖数: 3195 | 14 the constraint caused by the human factor is not going away.
shorter function is easier to understand, and therefore less bug prone. |
h********n 发帖数: 1671 | 15
这已经是很“现代”的观念了。过去对可读性和可维护性没有现在这样重视,反倒是鼓励许多“技巧”。现在看这些“技巧”有些已经失效,因为软硬件彻底改变了。有些虽然还有效但并不提倡,因为可读性和可维护性差。
正是因为不同时代的观念不一样,所以才不要死守一些“原则”。关于可读性也有许多原则在改变,过去显示器最多显示80列,现在宽得多;过去关键字两边要留空格便于识别,现在几乎所有编辑器都支持语法高亮;过去提倡匈牙利命名,现在不提倡;过去提倡使用STL algorithm简化函数体,把实际的操作写在函数外,现在又推出在函数内嵌入lambda function。虽然都是为了提高可读性,但是不同时代的原则是不一样的。
【在 g*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : It's not about long or short, but about readability which is almost : equivalent to quality for an application maintained overtime.
|
a***y 发帖数: 2803 | 16 cobol特别有意思,如果写成a-b,那么编译器以为是一个变量"a-b".如果要让a减去b,一
定要写成a - b,這個时候空格是必须的.
以前特别强调代码的简洁性,一个函数里面最好只有一个return,如果写多个return,就
有人觉得写得不够聪明.现在强调的是代码的可维护性,内存现在以gb为单位,但是维护
代码的人可能会跳槽,所以可维护性狠重要.
鼓励许多“技巧”。现在看这些“技巧”有些已经失效,因为软硬件彻底改变了。有些
虽然还有效但并不提倡,因为可读性和可维护性差。
多原则在改变,过去显示器最多显示80列,现在宽得多;过去关键字两边要留空格便于
识别,现在几乎所有编辑器都支持语法高亮;过去提倡匈牙利命名,现在不提倡;过去
提倡使用STL algorithm简化函数体,把实际的操作写在函数外,现在又推出在函数内
嵌入lambda function。虽然都是为了提高可读性,但是不同时代的原则是不一样的。
【在 h********n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : : 这已经是很“现代”的观念了。过去对可读性和可维护性没有现在这样重视,反倒是鼓励许多“技巧”。现在看这些“技巧”有些已经失效,因为软硬件彻底改变了。有些虽然还有效但并不提倡,因为可读性和可维护性差。 : 正是因为不同时代的观念不一样,所以才不要死守一些“原则”。关于可读性也有许多原则在改变,过去显示器最多显示80列,现在宽得多;过去关键字两边要留空格便于识别,现在几乎所有编辑器都支持语法高亮;过去提倡匈牙利命名,现在不提倡;过去提倡使用STL algorithm简化函数体,把实际的操作写在函数外,现在又推出在函数内嵌入lambda function。虽然都是为了提高可读性,但是不同时代的原则是不一样的。
|
g*****g 发帖数: 34805 | 17 I think these principles have been recommended on Java programming for as
long as it's there. And things like coding style haven't been changed.
鼓励许多“技巧”。现在看这些“技巧”有些已经失效,因为软硬件彻底改变了。有些
虽然还有效但并不提倡,因为可读性和可维护性差。
多原则在改变,过去显示器最多显示80列,现在宽得多;过去关键字两边要留空格便于
识别,现在几乎所有编辑器都支持语法高亮;过去提倡匈牙利命名,现在不提倡;过去
提倡使用STL algorithm简br />
【在 h********n 的大作中提到】![](/moin_static193/solenoid/img/up.png) : : 这已经是很“现代”的观念了。过去对可读性和可维护性没有现在这样重视,反倒是鼓励许多“技巧”。现在看这些“技巧”有些已经失效,因为软硬件彻底改变了。有些虽然还有效但并不提倡,因为可读性和可维护性差。 : 正是因为不同时代的观念不一样,所以才不要死守一些“原则”。关于可读性也有许多原则在改变,过去显示器最多显示80列,现在宽得多;过去关键字两边要留空格便于识别,现在几乎所有编辑器都支持语法高亮;过去提倡匈牙利命名,现在不提倡;过去提倡使用STL algorithm简化函数体,把实际的操作写在函数外,现在又推出在函数内嵌入lambda function。虽然都是为了提高可读性,但是不同时代的原则是不一样的。
|
y***d 发帖数: 2330 | 18 我觉得 80 列太窄了;现在的那些函数、变量名很多就是词组,什么“
RandomAccessFile”,什么“BufferedReader”;再加上 class-function-try-for 之
类的缩进,80 列造成很多不必要的换行。
比如 http://download.oracle.com/javase/tutorial/essential/io/charstreams.html,
try {
inputStream =
new BufferedReader(new FileReader("xanadu.txt"));
outputStream =
new PrintWriter(new FileWriter("characteroutput.txt"));
这不是折腾自己么;新时代应该以 120 列为标准了
【在 g*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : I think these principles have been recommended on Java programming for as : long as it's there. And things like coding style haven't been changed. : : 鼓励许多“技巧”。现在看这些“技巧”有些已经失效,因为软硬件彻底改变了。有些 : 虽然还有效但并不提倡,因为可读性和可维护性差。 : 多原则在改变,过去显示器最多显示80列,现在宽得多;过去关键字两边要留空格便于 : 识别,现在几乎所有编辑器都支持语法高亮;过去提倡匈牙利命名,现在不提倡;过去 : 提倡使用STL algorithm简br />
|
g*****g 发帖数: 34805 | 19 80, or 120 is not the key. The key is a consistent style in the team.
【在 y***d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我觉得 80 列太窄了;现在的那些函数、变量名很多就是词组,什么“ : RandomAccessFile”,什么“BufferedReader”;再加上 class-function-try-for 之 : 类的缩进,80 列造成很多不必要的换行。 : 比如 http://download.oracle.com/javase/tutorial/essential/io/charstreams.html, : try { : inputStream = : new BufferedReader(new FileReader("xanadu.txt")); : outputStream = : new PrintWriter(new FileWriter("characteroutput.txt")); : 这不是折腾自己么;新时代应该以 120 列为标准了
|
y***d 发帖数: 2330 | 20 what lock is this key for?
【在 g*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 80, or 120 is not the key. The key is a consistent style in the team.
|
|
|
h********n 发帖数: 1671 | 21 只有一个return的最主要的目的不是为了简洁,而正是为了可维护性。因为可能需要在
return之前做一些清理工作,如果将来有改动,只需要改一个地方。如果有多个return
,改动的时候有可能会不小心漏掉几个。同理还有循环里的break等,在结构化编程开
始流行的时候,这些都是很讲究的。现在有了RAII和exception,这些都不重要了。
【在 a***y 的大作中提到】![](/moin_static193/solenoid/img/up.png) : cobol特别有意思,如果写成a-b,那么编译器以为是一个变量"a-b".如果要让a减去b,一 : 定要写成a - b,這個时候空格是必须的. : 以前特别强调代码的简洁性,一个函数里面最好只有一个return,如果写多个return,就 : 有人觉得写得不够聪明.现在强调的是代码的可维护性,内存现在以gb为单位,但是维护 : 代码的人可能会跳槽,所以可维护性狠重要. : : 鼓励许多“技巧”。现在看这些“技巧”有些已经失效,因为软硬件彻底改变了。有些 : 虽然还有效但并不提倡,因为可读性和可维护性差。 : 多原则在改变,过去显示器最多显示80列,现在宽得多;过去关键字两边要留空格便于 : 识别,现在几乎所有编辑器都支持语法高亮;过去提倡匈牙利命名,现在不提倡;过去
|
l********a 发帖数: 1154 | 22 同意这个
目前"大多数"的程序,cpu的计算能力没什么问题
反倒可读性比较重要,哪怕要牺牲一点性能,代码不怎么fancy
return那个,我觉得最好只有一个
可以多个return就用一个变量的不同值来体现,最好还是return这个变量比较好
【在 g*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : It's not about long or short, but about readability which is almost : equivalent to quality for an application maintained overtime.
|
g*****g 发帖数: 34805 | 23 To have a consistent style enforced in the team. The best is to have
a formatter automatically format the code before commit. And the entire
team can use the same template they agree on.
【在 y***d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : what lock is this key for?
|
D*******a 发帖数: 3688 | 24 any suggestion of this formatter?
in my previous job we used StyleCop to enforce c# code rules
【在 g*****g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : To have a consistent style enforced in the team. The best is to have : a formatter automatically format the code before commit. And the entire : team can use the same template they agree on.
|
a***y 发帖数: 2803 | 25 恩,所以现在公司喜欢雇佣些18,9岁高中毕业生用perl什么的高级语言写程序,反正可读
性比简洁性更重要. 反正大部分软件都不需要3d游戏那样的高效管理内存.
【在 l********a 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 同意这个 : 目前"大多数"的程序,cpu的计算能力没什么问题 : 反倒可读性比较重要,哪怕要牺牲一点性能,代码不怎么fancy : return那个,我觉得最好只有一个 : 可以多个return就用一个变量的不同值来体现,最好还是return这个变量比较好
|
w********o 发帖数: 10088 | 26 包括注释么
【在 h**i 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 有人写了7000行
|
X****r 发帖数: 3557 | 27 我觉得我眼花了,居然看到perl和可读性在一句话里。
【在 a***y 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 恩,所以现在公司喜欢雇佣些18,9岁高中毕业生用perl什么的高级语言写程序,反正可读 : 性比简洁性更重要. 反正大部分软件都不需要3d游戏那样的高效管理内存.
|
l********a 发帖数: 1154 | 28 这个我也郁闷了一把,我以为是写python写错了
【在 X****r 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我觉得我眼花了,居然看到perl和可读性在一句话里。
|
x****u 发帖数: 44466 | 29 perl当然可以写的可读,但这样的人肯定通过不了perl面试。
【在 X****r 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我觉得我眼花了,居然看到perl和可读性在一句话里。
|
w********o 发帖数: 10088 | 30 你应该惊讶,perl居然放在高级语言的一类里
【在 X****r 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我觉得我眼花了,居然看到perl和可读性在一句话里。
|
|
|
y*******g 发帖数: 6599 | 31 perl为什么不算高级语言?
【在 w********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 你应该惊讶,perl居然放在高级语言的一类里
|
w********o 发帖数: 10088 | 32 好吧,看你怎么定义高级语言了
如果C也算高级语言的话,perl自然算
【在 y*******g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : perl为什么不算高级语言?
|
n******t 发帖数: 4406 | 33 perl当然是高级语言了。高级语言和可读性没有必然联系。。
lisp的可读性就不杂个。
【在 w********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 你应该惊讶,perl居然放在高级语言的一类里
|
w********o 发帖数: 10088 | 34 我觉得高级语言应该重新定义了
当C出来的时候,相对于汇编,被叫做高级语言,所以同时代的那一批都是高级语言
现在又有了这些面向对象的,应该换个说法了
【在 n******t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : perl当然是高级语言了。高级语言和可读性没有必然联系。。 : lisp的可读性就不杂个。
|
r****t 发帖数: 10904 | 35 your head picture looks like a qwt widget, is it?
【在 a****l 的大作中提到】![](/moin_static193/solenoid/img/up.png) : if someone did before, this person might be ashamed to tell the truth. If : this person did tell the truth, this person will feel ashamed afterwards.
|