习惯使用断言Assert

一直在给党做项目，我们这些可怜兮兮的学生都没太多时间安排自己的活动了，写个blog都要在中午休息的时间。

项目用的是.NET，本来也想分享一些干货点的东西，但博客园里的前辈把这类文章已经分享泛滥了，想要原创一些有价值的东西其实挺不容易的，能够在前人基础上拓展一下就已经挺不错了，相信每一个认真经营博客的人都挺有体会，所以在博客记录一些平时项目开发的感悟也不失为一个好地方。

Assert在整个项目开发中的重要性是很多人一直都忽略掉的，这一点从我接触到的项目来看，挺明显，可以说，它的出现频率与项目代码的质量成正比，如果一段代码综合水平比较高，那么几乎总会出现至少那么一两个断言，而断言的重要性又是在很多代码质量类的书上一直在强调的。

嘛，既然断言在Release时不会出现在最终版本中，那么Debug版本时，它是如何提升开发效率的？

        private void ShowProjectInfomation(string projectID)
        {
            Debug.Assert(!string.IsNullOrEmpty(projectID));
        }

假设我们需要一个项目的ID(projectID)，从数据集中取出这个ID对应的一个项目的具体信息，这个时候的背景条件是projectID一定会传进一个值，因为该函数并不以供给客户调用的形式存在。这个时候，如果这样写，并不是最好的做法。

        private void ShowProjectInfomation(string projectID)
        {
            if (string.IsNullOrEmpty(projectID))
            {
                throw new ArgumentNullException("项目ID不可为空");
            }
        }

抛异常的好处坏处很多书也有提及，此不赘述。

使用Assert，如果出现参数违法，此时开发阶段可以修正此错误，保证传进来的参数一定是合法的，那么在最终版本中，就避免了影响性能的错误检测代码。

啐。。。写文章的描述能力真的挺重要的，感觉好没耐心去准备一篇高质量文章，往往是想到什么就写。。。

这里想抱怨一下国家的一些项目，其实和坊间传的差不多，国家的项目的代码质量整体来说并不好，有些水平很好的老师也不太注重代码本身的质量，最基本的DRY并不遵守，导致干活儿的学生也盲目效仿，到处都有Bad Smell，代码规范不完整统一，导致后来维护的，编写的，都很难轻松地干完活儿。嗯。。。好在钱发的还挺多的。。。