答应过要发几篇心得的,第二篇:在 case 语句中使用字符串 (50分)

  • 主题发起人 主题发起人 beta
  • 开始时间 开始时间
看程序要注解,落后呀,呵呵,又不是什么高深算法
 
Another_eYes:
关于你说的这个问题,我这里有一条规则(或者说是建议吧):
清晰的程序(包括命名以及结构)胜过难懂的代码加上优美的注释。
(必要的注释是不可少的,但是不能用来代替清晰的代码)
这不是我说的,但是我非常赞同,并且一直这样用着。
 
对Beta3的说法深表赞同!
我记得在哪本书上看到过一个“自注释代码”的概念,就是说,一段设计良好的代码,其逻辑可以非常清晰的阅读出来。
注释在一些情况下可以成为“万恶之源:D”,比如:
1.注释中只是简单重复代码所作的操作(c=a+b;//把a和b的结果赋给c),我称其为“垃圾注释” :-(
2.修改过程中注释与代码不同步,一个错误或者过时的注释比没有注释还要来得糟糕的多,这种注释往往会误导读者,贻害无穷。
3.注释语言描述不清楚,一些程序员很难用自然语言来描述他们的意图,阅读的人理解起来还不如直接读高质量的代码来得清楚
4.自然语言的语种问题 :-( 且不提自然语言的理解,仅仅是字符集问题就已经够困扰的了,我曾经下载过其他语种的代码,注释往往和}结合起来,导致编译无法通过,只能一行一行的删除之。
当然,这并不是说我们不应该写注释,注释应该在下列情况下使用:
1.一个复杂的算法。这时穿插在代码行间的注释是非常有必要的(当然,不能是上述的第1类注释),往往需要搭配流程图
2.描述变量的作用。我想这是我们应该最常使用的注释之一
3.描述接口函数的作用和调用约定。尤其是后者!如果你的接口函数隐含了调用约定,那么一定要注释上。
4.帮助写的人和阅读的人理清思路。比如我进行复杂的画图等操作的时候往往先写注释,比如:
// 创建图象缓冲
// 画背景
// 画文字
// 画边框
// 实际画到画布
等,然后才去写对应的代码,这样思路要明确的多,即使这次没有写完,下次也很容易接着写。
5.特殊作用注释。比如// TODO: 注释,Delphi对其提供了特殊的支持。
 
P.S. 王寒松大侠也并非只存在于离线包中呢,有时还是露露面接受大家景仰的 :D
 
叮叮当当的代码可以这样改进:
type
TCityName = (cnShangHai, cnBeiJing, cnChongQing, cnWuHan);
EUnknownCityName = class(Exception);
...
case TCityName(AnsiIndexStr(City, ['上海', '北京', '重庆', '武汉'])) of
cnShangHai: {上海}
;
cnBeiJing: {北京}
;
cnChongQing: {重庆}
;
cnWuHan: {武汉}
;
else
Raise EUnknownCityName.Create('Unknown city name!');
end;

当然,可以进一步封装成function GetCityID(Name: string): TCityName;函数,这样更清晰一些。
 
BETA小弟,动不动就来一个心得,这个可能是我唯一能看明白的,所以甚是欢喜。你的文笔怎么
也不能让我联想到你的形象,意思就是你说话象大拿。
 
// 说话象大拿
“大拿”什么意思?
请 JJ 明示。
 
大拿,就是大家拿,呵呵
就是你是高手,大侠,权威呗
 
JJ?女程序员可是稀有动物啊!
 
精彩!我等小辈无言可发,只有学习的份!
go on
 
哈哈,我还以为大拿是打错字了。
 
差不多了,结帖吧。分数乃乱序分配,见谅。
 
好的 Hash 散列算法至今未有定论,对字符串而言的 Hash 算法一般只处理前面 8 位字符(比如Java),
Hash 值判断在近似字符串的判断上不足取,IndexOf 通用的多
 
精华贴,让新手小弟受益颇多,收藏之
 

Similar threads

S
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
900
SUNSTONE的Delphi笔记
S
后退
顶部