我们的终极编码规范_项目管理_非技术区_程序员俱乐部

我们的终极编码规范，最重要的只有3点：

1. 每一个文件不能超过300行代码，最好不超过200行；
2. 每一个方法不能超过30行代码；
3. 不写一行注释。

这3点看上去很简单，但是很多人做不到，即使是多年工作经验的。我们提出这3点，有很多人不相信做得到，或者认为即使做到实际意义也不大。事实是，我们多个项目成功做到了这3点，我们的团队深刻体会到了写代码的优雅、写代码的艺术。

这3点应该在所有项目中遵守，不管是c#，还是js、HTML、java，都应该尽可能达到。

除了这3点，还有其他几点可供参考：

1. 每一个文件夹不能超过30个文件和子文件夹，对于架构而言；
2. 业务相关的代码一定要放到一起；
3. 尽可能降低各个类的耦合度；
4. 写任何代码，当性能不是问题的时候，都应该把代码写的更易读。

命名指导：

对于日期和时间的命名。如果存的值只是日期，那么以Date结尾；如果值是时间，那么以Time结尾。如：CreatedDate代表这条记录的创建日期，不包含时间；CreatedTime代表这条记录的创建时间，包含日期和时间。

命名要准确，不可模糊。不能因为命名太长而选择有歧义或模糊意义的命名。比如以前项目中的一个案例：数据库中有一个“Recipe（菜）”表，做这个菜的时间包含：PrepareTime, CookTime, OvenTime, CleanTime。这里的命名有问题，因为调用者不知道这里Time是存的秒还是分还是带小数的小时，于是改成：PrepareMinutes, CookMinutes, OvenMinutes, CleanMinutes。另一个常见例子是，单词“interval”用作命名的时候，调用者也不清楚是分钟还是毫秒，于是后面都要加单位。

Bool类型返回值的方法，除了is做前缀外，还有can, will, does, has, should。以前在项目中看到一个方法，叫IsReceiveMessage，我在想是不是IsReceivingMessage，因为很多国内程序员英语语法不好，但后面我看到注释才发现，这个方法实际上是判断用户是否能收到短信，也就是说这个方法应该叫CanReceiveMessage。我相信写这个方法的程序员，写完这个方法命名时，肯定自己读着也感觉不太懂，所以加了个注释。实际上所有加注释的地方，要么命名不准确，要么方法太长。一旦你发现自己在写注释，那么你就需要思考这2个问题了。

未完待续，本帖长期更新中...