谢谢大家对本系列第一篇写出优雅简明代码的论题集 -- Csharp(C#)篇[1]的回复和讨论,我相信针锋相对的辩论不仅有助于发现答案,更让我们了解问题后面的实质。
对程序员而言,我们的代码需要:
1. 在预算内实现需求,让用户可以使用 -- 让自己或者公司可以赚到钱
2. 方便自己修改及日后维护
3. 方便别人修改及日后维护
4. 便于重复使用,为以后的开发节省时间
5. 让系统高效的运作
从美国商学院毕业的学生们掌握了很多相似的思维模式,这不仅有利于他们解决问题,更重要的是方便他们彼此之间沟通。-- 换句话说,他们毕业后都安装上了相同的协议和一些可通用的接口,这样有一个基础平台可以让他们协同工作。
论题七:命名规范
也许有人认为没有必要再提这个问题,但在日常编码生活中,这的确是一个很重要的话题。
7.1 类名、方法、常数使用Pascal casing
{
const int DefaultNumber = 100 ;
public void MyMethod()
{ }
}
7.2 局部变量,参数用camel casing
{
int number;
}
7.3 interface 名字以I 开头
7.4 尽量不用单个字符命名变量,象 i 或者 t 。使用 index 或者 temp 之类代替。
7.5 将所有来自framework 的 namespace 放在前面,而后再放第三方或自定义的:
using System.Linq;
using System.Data.Linq;
using System.Collections.Generic;
using System.Text;
using System.ComponentModel.DataAnnotations;
using CodeSmith.Data.Attributes;
using CodeSmith.Data.Rules;
论题八: 一个方法的参数不能超过5个,当多于5个时,应进行函数的拆分或者参数的封装。-- 嚯嚯就像论题一样的规定
一些说明:不是为了给自己一个紧箍咒,而是在日常编程中,我们发现如果你写的方法不满足这样一个条件,一年后,就算是你自己也不太想去维护和修改,如果换成是其他程序员会对此更加的头痛,对吗?
论题九: 不要滥用注释,有些非常清晰明确的代码不需要注释
仅在必要的时候注释你的代码,不要太多,并且注释也要简单给力。
论题十: 不要把数值hard-code在代码中,使用const 来定义
论题十一: 不要使用””, 使用string.Empty
正确的:
不建议:
论题十二: 善于合并if
观察下面这段可爱的代码:
if ( ! CommentId.Equals(obj.CommentId)) return false ;
if ( ! Comment.Equals(obj.Comment)) return false ;
if ( ! CommentorId.Equals(obj.CommentorId)) return false ;
return true ;
}
如果我们写成这样会不会好些呢:
return CommentId == obj.CommentId &&
Comment.Equals(obj.Comment) &&
CommentorId == obj.CommentorId;
}
观察下面这段可爱的代码:
if ( ! CommentId.Equals(obj.CommentId)) return false ;
if ( ! Comment.Equals(obj.Comment)) return false ;
if ( ! CommentorId.Equals(obj.CommentorId)) return false ;
return true ;
}
如果我们写成这样会不会好些呢:
return CommentId == obj.CommentId &&
Comment.Equals(obj.Comment) &&
CommentorId == obj.CommentorId;
}
论题十三: 不断重构你的代码
当有新的需求或新改动的时候,可以拨一些时间来重构。 -- 你可能突然发现,原来重构后的代码可以如此美丽。使用一些重构的插件,比如resharper可以使你事半功倍。
未完待继…