提高我的代码质量

关于写代码，严格遵从某种良好的习惯，会给你带来意想不到的效果，它是一种提高你效率最简单、代价最小的一种方式。

接下来，作者会介绍个人认为比较好的编码习惯，仅供大家参考交流。

关于编码习惯，大多数来自《代码大全》

关于设计，则来自《敏捷开发-敏捷软件开发：原则、模式与实践》

这里写的是总结，作者会提到用什么方法解决某类什么问题，具体细节各位读者自己查找，都是比较容易找到相关资料的（程序员不能沉下心来研究问题，那可能是选错了行），废话不多说，直入主题

1、如果你代码的if...else或者switch...case是那种很长的结构，那么我建议你使用表驱动法，它能大量减少你的代码量，并且提高你代码可读性，可读性上来的，代码质量也会跟着上来。

代码大全十八章中有详细介绍。

2、给你的程序加上日志，不管是自己写的简单日志还是使用log4net这种第三方库，它能大大节省你找bug的时间，日志文件甚至会告诉你在哪行发生了错误，接下来的操作无非就是在出错的位置打个断点调试并解决问题，这一套下来没几个bug顶得住。

3、最开始学习程序时，接触到try catch块，当时就爱上了它，因为它能包容你的所有错误（把你的bug藏起来），如下面的代码块，catch住的异常不错任何操作，就这么藏着，只要程序不崩溃，就是没问题。^-^

            try
            {
                //TODO...
            }
            catch (Exception ex)
            {

            }

大家千万别空的异常捕获语句，直接导致的后果就是程序出了问题，但是找不到问题出在哪里，程序应该尽可能的往外抛异常，而不是在深层次的接口捕获异常，接口尤为重要，不能用异常来推卸责任。你见过几个revit接口不抛出异常的吗?

只有真正例外的情况下才抛出异常，也就是仅在其他编码实践方法无法解决的情况下才使用异常。异常的应用情况跟断言类似---都是用来处理那些不仅罕见甚至永远不该发生的情况。

4、断言是指在开发期间使用的、让程序在运行时进行自检的代码，对于大型的复杂程序或可靠性要求极高的程序来说尤其有用。

我个人开发的程序，所有接口的传入参数，都会使用断言，如下构造函数：

        public SharedParameterService(Document document, string shareParamFileName = "")
        {
            System.Diagnostics.Debug.Assert(document != null);

            _document = document;

            if (!string.IsNullOrEmpty(shareParamFileName))
            {
                if (!shareParamFileName.ToLower().EndsWith(".txt"))
                    shareParamFileName += ".txt";

                ShareParamFileName = shareParamFileName;
            }
        }

用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况。

避免把需求执行的代码放到断言中，因为release版本中，断言语句会被忽略。

对于高健壮性的代码，应该先使用断言再处理错误。

20200809

---

 

该篇文章会持续更新，慢慢积累，是本人的笔记，更希望给读者一些些启发，那就是有意义的。。。