h**i
发帖数: 712 | |
a*w
发帖数: 4495 | 2 我念本科时写过3000行的，用Turbo C 2.0搞的。
【在 h**i 的大作中提到】
: 有人写了7000行
|
g*****g
发帖数: 34805 | 3 No function should be beyond 500 lines. Actually I can't
tolerate function longer than 200 lines.
【在 h**i 的大作中提到】
: 有人写了7000行
|
l********a
发帖数: 1154 | |
g**e
发帖数: 6127 | 5 函数太多读起来也累，跳来跳去
【在 l********a 的大作中提到】
: 超过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 的大作中提到】
: 有人写了7000行
|
S**I
发帖数: 15689 | 7 I once wrote a function with 5,000 lines when I was young, kind of ashamed
afterwards. :)
【在 a****l 的大作中提到】
: 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 的大作中提到】
: 函数太多读起来也累，跳来跳去
|
|
|
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 的大作中提到】
: 这个问题不同时代的原则是不一样的。过去曾经鼓励写超长函数，因为那时编译器的
: 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 的大作中提到】
: 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 的大作中提到】
:
: 这已经是很“现代”的观念了。过去对可读性和可维护性没有现在这样重视，反倒是鼓励许多“技巧”。现在看这些“技巧”有些已经失效，因为软硬件彻底改变了。有些虽然还有效但并不提倡，因为可读性和可维护性差。
: 正是因为不同时代的观念不一样，所以才不要死守一些“原则”。关于可读性也有许多原则在改变，过去显示器最多显示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 的大作中提到】
:
: 这已经是很“现代”的观念了。过去对可读性和可维护性没有现在这样重视，反倒是鼓励许多“技巧”。现在看这些“技巧”有些已经失效，因为软硬件彻底改变了。有些虽然还有效但并不提倡，因为可读性和可维护性差。
: 正是因为不同时代的观念不一样，所以才不要死守一些“原则”。关于可读性也有许多原则在改变，过去显示器最多显示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 的大作中提到】
: 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 的大作中提到】
: 我觉得 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 的大作中提到】
: 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 的大作中提到】
: cobol特别有意思,如果写成a-b,那么编译器以为是一个变量"a-b".如果要让a减去b,一
: 定要写成a - b,這個时候空格是必须的.
: 以前特别强调代码的简洁性,一个函数里面最好只有一个return,如果写多个return,就
: 有人觉得写得不够聪明.现在强调的是代码的可维护性,内存现在以gb为单位,但是维护
: 代码的人可能会跳槽,所以可维护性狠重要.
:
: 鼓励许多“技巧”。现在看这些“技巧”有些已经失效，因为软硬件彻底改变了。有些
: 虽然还有效但并不提倡，因为可读性和可维护性差。
: 多原则在改变，过去显示器最多显示80列，现在宽得多；过去关键字两边要留空格便于
: 识别，现在几乎所有编辑器都支持语法高亮；过去提倡匈牙利命名，现在不提倡；过去
|
l********a
发帖数: 1154 | 22 同意这个
目前"大多数"的程序,cpu的计算能力没什么问题
反倒可读性比较重要,哪怕要牺牲一点性能,代码不怎么fancy
return那个,我觉得最好只有一个
可以多个return就用一个变量的不同值来体现,最好还是return这个变量比较好
【在 g*****g 的大作中提到】
: 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 的大作中提到】
: 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 的大作中提到】
: 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 的大作中提到】
: 同意这个
: 目前"大多数"的程序,cpu的计算能力没什么问题
: 反倒可读性比较重要,哪怕要牺牲一点性能,代码不怎么fancy
: return那个,我觉得最好只有一个
: 可以多个return就用一个变量的不同值来体现,最好还是return这个变量比较好
|
w********o
发帖数: 10088 | 26 包括注释么
【在 h**i 的大作中提到】
: 有人写了7000行
|
X****r
发帖数: 3557 | 27 我觉得我眼花了，居然看到perl和可读性在一句话里。
【在 a***y 的大作中提到】
: 恩,所以现在公司喜欢雇佣些18,9岁高中毕业生用perl什么的高级语言写程序,反正可读
: 性比简洁性更重要. 反正大部分软件都不需要3d游戏那样的高效管理内存.
|
l********a
发帖数: 1154 | 28 这个我也郁闷了一把,我以为是写python写错了
【在 X****r 的大作中提到】
: 我觉得我眼花了，居然看到perl和可读性在一句话里。
|
x****u
发帖数: 44466 | 29 perl当然可以写的可读，但这样的人肯定通过不了perl面试。
【在 X****r 的大作中提到】
: 我觉得我眼花了，居然看到perl和可读性在一句话里。
|
w********o
发帖数: 10088 | 30 你应该惊讶,perl居然放在高级语言的一类里
【在 X****r 的大作中提到】
: 我觉得我眼花了，居然看到perl和可读性在一句话里。
|
|
|
y*******g
发帖数: 6599 | 31 perl为什么不算高级语言？
【在 w********o 的大作中提到】
: 你应该惊讶,perl居然放在高级语言的一类里
|
w********o
发帖数: 10088 | 32 好吧，看你怎么定义高级语言了
如果C也算高级语言的话，perl自然算
【在 y*******g 的大作中提到】
: perl为什么不算高级语言？
|
n******t
发帖数: 4406 | 33 perl当然是高级语言了。高级语言和可读性没有必然联系。。
lisp的可读性就不杂个。
【在 w********o 的大作中提到】
: 你应该惊讶,perl居然放在高级语言的一类里
|
w********o
发帖数: 10088 | 34 我觉得高级语言应该重新定义了
当C出来的时候，相对于汇编，被叫做高级语言，所以同时代的那一批都是高级语言
现在又有了这些面向对象的，应该换个说法了
【在 n******t 的大作中提到】
: perl当然是高级语言了。高级语言和可读性没有必然联系。。
: lisp的可读性就不杂个。
|
r****t
发帖数: 10904 | 35 your head picture looks like a qwt widget, is it?
【在 a****l 的大作中提到】
: 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.
|
