[讨论]无注释编程以前LZ也是一个满篇注释的Coder,但是自从到这个公司,除了写别人调用的api,有个简单的api
[讨论]无注释编程
以前LZ也是一个满篇注释的Coder,但是自从到这个公司,除了写别人调用的api,
有个简单的api功能描述,其他什么都没有。
OK,我就不光说不练了,给大家看看我的代码先。
C# codeusing System;using System.Collections.Generic;using System.Text;using System.Collections;using System.Collections.Specialized;using System.Web;using System.IO;using XXX.Lib;namespace XXX{ // Url辅助类:对Url进行初步的解析 public class UrlHelper { const int MAX_URI_LENGTH = 512; string _scriptName = string.Empty; CommandResult _parseResult = CommandResult.Success; NameValueCollection _parameters = new NameValueCollection(); char[] _uriInvalidChar = new char[] { '/', '\\' }; char[] _pathInvalidChar = new char[] { '/', '\\', ':', '*', '?', '\"', '<', '>', '|' }; public Uri _uri = null; public string ScriptName { get { return _scriptName; } } public NameValueCollection Parameters { get { return _parameters; } } public CommandResult ParseResult { get { return _parseResult; } } public UrlHelper(Uri originalUri) { _uri = ReplaceUri(originalUri); if (IsUriLengthError()) { return; } if (CheckPathAndQuery()) { ParsePathAndQuery(); } } private Uri ReplaceUri(Uri originalUri) { string uriStr = ReplaceUriWithUrlModel(originalUri); if (uriStr == "") { return originalUri; } else { return new Uri(uriStr); } } private static string ReplaceUriWithUrlModel(Uri originalUri) { string[] splitStr = null; try { foreach (var item in File.ReadAllLines(Hisan.Lib.SystemLib.GetAppRootDir() + "UrlModel.ini")) { splitStr = item.Split(new string[] { "->" }, StringSplitOptions.RemoveEmptyEntries); if (splitStr == null || splitStr.Length != 2) { continue; } if (splitStr[0].Trim() == originalUri.PathAndQuery.Substring(1)) { return originalUri.AbsoluteUri.Replace(splitStr[0].Trim(), splitStr[1].Trim()); } } } catch { } return ""; } private bool IsUriLengthError() { if (_uri == null || _uri.ToString().Length > MAX_URI_LENGTH) { _parseResult = CommandResult.UrlTooLong; return true; } return false; } private bool CheckPathAndQuery() { string pathAndQuery = _uri.PathAndQuery.Substring(1); if (IsUrlInvalidChar(pathAndQuery)) { return false; } if (pathAndQuery.IndexOfAny(_uriInvalidChar) >= 0) { _parseResult = CommandResult.UrlInvalidChar; return false; } else if (pathAndQuery.Length == 0) { _parseResult = CommandResult.NoExistsMethod; return false; } string[] splitPathAndQuery = new string[] { }; if (IsFileNameInvalidChar(pathAndQuery, splitPathAndQuery)) { return false; } return true; } private bool IsFileNameInvalidChar(string pathAndQuery, string[] splitPathAndQuery) { splitPathAndQuery = pathAndQuery.Split(new char[] { '?' }, StringSplitOptions.RemoveEmptyEntries); if (splitPathAndQuery[0].IndexOfAny(_pathInvalidChar) >= 0) { _parseResult = CommandResult.FileNameInvalidChar; return true; } return false; } private bool IsUrlInvalidChar(string pathAndQuery) { if (pathAndQuery.IndexOfAny(_uriInvalidChar) >= 0) { _parseResult = CommandResult.UrlInvalidChar; return true; } return false; } private void ParsePathAndQuery() { string[] splitPathAndQuery = _uri.PathAndQuery.Substring(1).Split(new char[] { '?' }, StringSplitOptions.RemoveEmptyEntries); SetScriptNameAndParameters(splitPathAndQuery); } private void SetScriptNameAndParameters(string[] splitPathAndQuery) { _scriptName = splitPathAndQuery[0]; if (splitPathAndQuery.Length > 1) { _parameters = HttpUtility.ParseQueryString(splitPathAndQuery[1], Encoding.UTF8); } } }}
有人会问,为什么写成这么多小方法,其实这个是来源于一本书 CleanCode,而不写注释的想法也是来源于这本书。
文章中心思想是为了以写故事的方式来写程序。
拿出一小段为例,我给加上中文注释看看效果如何。
C# code public UrlHelper(Uri originalUri) { //替换Uri,如果跟进这个方法看的话,会发现把原来的请求更换成已经内置好的Url,这个是为了兼容旧版本Url的,当然这个本不应该存在,但当时那个版本没有自动升级,所以这个没办法。权且当成合适的好了,而且这也不是本次讨论的重点。 _uri = ReplaceUri(originalUri); //如果Uri的长度错误 if (IsUriLengthError()) { //返回 return; } //如果检查路径和查询成功(路径和查询这个暂且这么叫,这个做过Web的都知道Uri.PathAndQuery是获得host后面的字符串的。 if (CheckPathAndQuery()) { //解析路径和查询 ParsePathAndQuery(); } }
其实写程序也无非这样,根据汉字的意思就可以知道构造函数到底做了什么,想做什么。
不写注释的原因是一些简单的单词对于程序员来说是绝对看的懂的。
我们的英文虽然不怎么样,但说实话,就算写成中国版的英文又如何?他只能笑你不会英文,但不会笑你程序写的不好。
而且我相信这个大家都看的懂(在公司没有老外的情况下,否则真应该规范下英语了)
另外一个原因是维护的时候,或者修改Bug的时候大多数人都会忘了去修改注释,导致注释和程序不匹配。
这样后来的人看注释和程序不匹配,他就会想到底哪个错了。就算他不想,只认为程序是对的,OK。
那他还要想改不改错误的注释呢?虽然这个是不应该出现的问题,但这种问题却常常出现。
当然这种方法利弊都有,下面说下弊端。
1.对开发工具要求较高,当然VS还是很给力的,F12就可以跟着方法名进入方法。
但一些没有此功能的开发工具来说,去那么多代码中来找对应的方法,还是很头疼的。
2.较大的项目不太适合,比如一些开源的。那么多类,还全是英文,没有注释,找起来着实头疼。另外一般那样的项目修改的人很多,出现几个不受规矩的程序员就着实让人头疼,他看着别人不写注释自己也不写,但是逻辑组织的又不是很好。
本文仅作抛砖引玉之用,看看大家对无注释编程有何看法,以及普遍程度如何。
但就目前来看,大多数人看到没有注释的程序都会大喊“垃圾”。尤其篇幅较长的。但有些篇幅较长的确实是因为其特殊性没有办法进行小方法拆分,比如一些特殊的算法,拆开了反而逻辑不好。
[解决办法]我的函数名 有的用汉语拼音,有的用英语,看着好恶心好恶心。
比如 User Beep
比如 yonghu ICka
我觉得对于我这种菜逼 加上_下划线 好看一点
例如 yonghu_ID
哈
[解决办法]两个极端。一个不写,另一个太多。
[解决办法]我一般函数名都用英语,基本上显而易见的方法就不写注释,一些比较重要的地方就写注释,这样自己查起来也方便~
注释还是很好的呀!!!
[解决办法]还是适当的注释点好啊!
[解决办法]我也是
[解决办法]除非记忆力超群,否则自己写的代码,放到2/3年后,即使自己看也头大.适量注释还是很不错的.书写code时候也是一个思路的整理过程
[解决办法][解决办法]我觉得注释就是给自己提示用的, 想起什么事情来了怕忘, 就直接写注释里.
[解决办法]完全没有注释是不可取的,实践可以证明,走极端通常是错误的
还是要适当写点注释
[解决办法]如果程序是供别人调用的接口。我们希望在编程的时候调用别人的接口时,就能看到相关的提示和参数说明以及异常(就像ms)。 因此,肯定需要注释,但注释到什么地步就看编程的习惯了。
如果函数保持精练短小,那么注释就到函数说明、参数就可。每个类的头描述也是需要的。
如果是算法较长,中间也加。
[解决办法]有时编程还是会省掉。
不过回头看到没有注释的程序时还是会不自觉的加上的。建议下个stylecop软件试试。另外程序注释有了,生成相关的文档就方便了。
[解决办法]我建议还是最好加上注释 假如你学c++ 但是老板突然叫你学c# 1年后在叫你去搞c++ 肯定有点陌生
那么你拿注释的代码来一看 就了解了
有注释的代码更便于维护升级
[解决办法]对于有没有注释,其实是一种编程习惯的问题。初学者可以多参考别人的代码。时间久了,就应该形成自己的一种编程习惯。因为你写的代码更多时候是给你一个人看的,不是给别人看的。所以,只要你回过头来,看的懂自己的代码就可以了。
[解决办法]感谢lz分享。
------解决方案--------------------
注释适当的写写还是可以的
[解决办法]还是需要点注释的,不然以后自己回头看都不知道什么意思了
[解决办法]非常复杂的逻辑算法就写个注释,其他的就算了。
[解决办法]别走极端就好。有需要的地方,为方便理解,可适当加一点注释。
[解决办法]无注释的人写的程序通常是逻辑混乱的--他的程序结构连注释都没法加上去。
注释无效的,通常不知道该注释什么--也是能力问题。
如果你的实现(即代码)是错误的,那看的你就不知道你在干什么!
所以,我的注释是说明我“要干什么,以及实现中的特别之处”,当我的实现有错或需求变化而要修改时,让别人一看就会说“不是这么做的”,“应该改成这样”。
通常是“一行注释注明目的/步骤,接着几行实现的代码,下一个目的/步骤前一定有空行”。
[解决办法]加注释挺好的吧,方便以后的维护与扩展吗
[解决办法][解决办法]还好,各有所爱,谢谢分享。。。
[解决办法]注释是肯定要写的。。
[解决办法]该写的地方就要写
[解决办法]不写注释肯定是不行的, 但是也没有必要每句都写,很明显的很清楚的在写只会看着不舒服。 不是太明白的加点注释,言简意赅的描写功能。 一点不明白的要写详细点。 水平越高,注释一般较少,这是对个人而言,如果在公司,水平高的人,也替别人想,关键的地方还是给加下注释, 毕竟菜鸟多啊。
[解决办法][解决办法]我是来学习的
[解决办法]命名规范,控制好代码格式的前提下,可以减少注释
有些地方还是加上注释为好,看情况
[解决办法]不写注释的程序 保证1个月后 你自己回来看都要先看一半天才能理解
[解决办法]适当的应该添些注释,要不然以后会很崩溃。。。
[解决办法]C#也有注解??
[解决办法]没注释等于谋杀
[解决办法]一个人的程序
[解决办法]在软件开发过程中,伪代码编写是在正式代码编写之前的,一般会把伪代码中的一些内容作为注释。我是在代码大全中看到的。
[解决办法]个人认为注释还是需要的,代码移交给别人后,有注释会方便很多。
[解决办法]有些关键的注释还是必须得
[解决办法] 经常写注释的飘过
[解决办法]CleanCode
[解决办法]做事不能极端。满篇的注释在多方合作的时候是有用的。而如果没有注释,则会浪费新接收者的时间。
做事要讲究个度。不能一下就说什么好,什么不好。
[解决办法]只要代码结构合理,基本就无需写注释,因为很多方法名,属性名,类名都能很清晰的解释出这些代码是用来做什么的。
------解决方案--------------------
复杂的业务逻辑肯定会写, 其他的看忙不忙
[解决办法]可怕就可怕在有的程序员不仅英语不过关,汉语也不过关.写代码的动词名次都能弄错,写个请假条都语句不通顺.这样的程序员有木有?这样的程序员写不写注视都看不懂的
[解决办法]无注释编程(楼主的意思不是一点注释都没有)那就是需要一些注释的编程,必要的地方需要增加注释。那可能和命题有点冲突。
[解决办法]复杂逻辑写上注释,其他基本根据方法名,变量名就可以了。
[解决办法]注释是帮助你读懂 程序结构
没有注释一般情况是不可取的
[解决办法]决定把自己的项目从头至尾看一遍,然后把该注释的地方添上注释
[解决办法]必要的注释是要写的
[解决办法]如果你想把你的代码交给别人维护,那么适当的注释是必不可少的
(注:意味着你再也拿不到BOSS一分钱了)
如果你想自己来维护代码,而让别人束手无策,那就尽量不要注释
(注:BOSS只有找你,短期来看,钱滚滚而来,长期嘛,就要看个人能力了)
[解决办法]注释也是写给未来的自己阅读的
[解决办法]实际上,注释不一定是让别人看懂自己的代码,有时候也是给自己查找起来方便。我去年做一个项目时,突然想起来很久以前自己做的一段功能代码可以用上,但是那段代码在一大堆代码中藏匿着,我不得不去一个个的看。有了注释,我很容易就找出来我所需要的东西。这大概就是与人方便自己方便。
[解决办法]方法名长与短这个关系不大,但方法名一定要清晰
比如:如果分类id查找所有的产品名称,并分页
个人认为好:getProductNameListByCateIDPage
不好:getnames,getNameList 等等
需要方法名简单,但未能描述出方法的功能
我个人观点:让人看到这个方法名就能知道这个方法大概实现什么功能,长一点关系不大(总不能一个方法超过100个字符吧?!)。
至于你的方法名用什么类型,驼峰,下划线等等,看规范了。。。
------------------
关于注释:
像楼主所示的注释,可以基本不写,因为看方法名就知道大概了。
但关键的,比如一个判断分支,变量名,标识等等,比较重要的(个人认为),或者后面多用到之类的,最好注释一下。
-------------------
以上是我个人观点
[解决办法]还是有注释的好,虽然我也不太喜欢写这东西,但是我偶尔也在一些关键的地方加上注释,毕竟就算看的懂 也能节约时间
[解决办法]别用拼音写啊,看着头疼
[解决办法]没有注释是不行的,我只能说没注释害人害己
一、没注释,以后自己看不方便
二、如果你接手的代码,没注释,修改的时候就悲剧了,那时候你也只能无奈的骂一声,然后埋头自己一点一点的
分析代码,有时候分析的还不一定对
[解决办法]还是要看代码的内容是啥子,以及代码是写给谁看的,用于什么的
比如说页面上就三四个按钮的点击事件,已经非常简单,控件随意命名下,后台页面方法也就三四个,对于维护的人来说,一看就清楚,这种情况就不用写注释了吧
对于方法中的逻辑,如果逻辑较强,在关键之处还是应该要注释,除此之外,少写也不会有什么问题
一句话,不要写废话,不要让自己写得难受,也不要让别人看着难受
[解决办法][解决办法]呃...我知道我写的代码不注释的话,我自己都不知道是干嘛的..
[解决办法]适当注释吧,多了也不好 没有 有时候也不行啊
[解决办法]写注释,我向来看心情……
[解决办法]我也比较支持这个风格.
每个方法尽量简单.
我觉得我们写代码和写文章一样,就是在描述事情.
这个时候还需要注释,说明我们code没有把我们想表达意思表达出.
当然完全没有注释,也确实行不通,比如一些算法上,别人可能不理解,这时候需要写出想法.
我最近在改一个老项目的bug.
经常会发现一些坑爹注释.
如:int type; //1:....,2:....,3:.....
最后调来调去发现实际的东西和注释并不一样.
像这种情况,可以在set方法里去常量类的数据.然后把常量的名字取得好一点.
当然这个地方有魔鬼数字的问题,但是这个注释,引导我做了错误想法和判断.
越到后来,越来越不想念注释了.确认有人会代码,重构代码,但不会修改注释.
错误的注释比没有注释的问题要大得多,个人感觉.
总之,首先不是考虑把代码写得尽量清晰,易懂.
实在没有办法的时候,还是要补上注释.毕竟实际很难做到无注释编程.
另外,我也看了clean code了,受了蛮多启发的.
[解决办法]
确实你现在要是提,无注释编程.
99%程序员,都会说你不是好程序员.
哈哈
[解决办法]
看书要有书签,
看代码必须有注释,当然注释要正确。(我写的注释有时连我都看不懂)
[解决办法]
不知道大家有没有发现。反正我在vs里面写方法和定义变量都直接用中文,这边既不用注释也不用担心别人不懂英语。哈哈!
[解决办法]
还是写点好,不过自己没有不写注释的习惯!!!
[解决办法]
又看到这种观点了!
既然都说无注释,又说不是一点注释不加。
或者归纳为 该要的注释还是要的,不该要的不要。
怎么听怎么像废话。
还不如说要加强提高写注释的水平,提高代码的可读性。
(或者说标题党比较好)
[解决办法]
我觉得使用索引型(或使用超链接)注释挺好的,至少在重构和修改时,会方便很多
如果是直接在代码里面写注释的话,建议精简精简再精简,因为一旦产生重构,修改注释的工作量远远大于修改代码的工作量
[解决办法]
适当的写还是有好处的。
[解决办法]
注释还是要写滴。。。
[解决办法]
帮你顶顶帖子,学习一下