消除代码中的坏味道，编写高质量代码
Intro
想要写出较好的代码，保证代码的高质量需要时刻警惕代码中的坏味道，今天分享一下，我觉得平时写的代码中可能会出现的坏味道代码的一些示例
常见的坏味道代码
Bug Logically(null check etc.)
严格的来说，这可能是一个 BUG 级别的代码了，最简单的一个实例，你应该明确你的输入数据是不是可能为 null，如果可能为 null 需要检查一下，有一些代码中往往会在代码中写下一些坑，明明这个变量是 null 还是直接用这个变量中的属性或方法
还有一种情况是明确对象不是 null 的情况下就不要 null check 或使用 null 传播符号，下面的这个是一个错误示例：
var list = new List<int>(){1,2,3,-2,3,6,2};
var arr = list?.Where(x=>x>0)?.Where(x=>(x%2)==0)?.ToArray()
上面的代码里 list 是不会为 null 的所以 list 后不需要加 ?，Where 这个 LINQ 方法是不会返回一个 null 的，所以 Where 后面也是不需要加 ? 的
这里特别想说一下，很多人对象 First 和 FirstOrDefault 的用法有些不清楚，如果能找到数据并且要找到第一个数据就用 First，如果找不到会有 exception， 而 FirstOrDefault 在不确定有没有的时候用它更合适，如果没有就返回一个默认值。
unnecessary namespace using
代码中没有用到的命名空间引用请移除它，避免不必要的代码
unused code, commented code
没有用到的代码或者被注释的代码直接从代码中删除，不要保留在代码库中，一个是可能会让人很费解，一个是没有任何用处
现在我们的代码基本都会使用源代码版本管理，如果没有，我建议你使用，这样可以保证每次修改都是一个版本，可追溯
exception throw
在应用中主动抛异常的时候应该抛出具体的异常，例如参数为 null 的时候应该抛出 throw new ArgumentNullException("paramName") 而不是 throw new Exception()
还有一些异常应该是系统内部抛出的异常，不应该从用户代码中抛出，例如：IndexOutOfRangeException
obsolete members
对于过时的方法，我们一般会标记一个 [Obsolete]，标记的同时应该提供一个 message 提示用户不要使用这个方法或者使用哪一个方法代替
抽象类
抽象类的构造器方法应该是 protected，因为抽象类是不能实例化的，所以抽象类的构造方法是不是被直接调用的，所以通常来说应该考虑抽象类的构造方法设置为 protected
抽象类中外部要使用的方法才设置为 public，仅内部会用到的成员设置为 protected 即可，体现封装特性，最小化访问权限
方法重载
方法重载应该放在一起，这样方便我们查找代码，也会更方便了解这个方法的参数
method complexity
减少方法的复杂度，不要让一个方法过于复杂，如果太复杂了就可能需要考虑重构了，方法参数不能太多，方法逻辑不要太复杂，详细可以参考上一篇文章方法重构分析
IEnumerable<T>
对于 IEnumerable<T> 使用 Any() 来代替 Count()==0
对于数组和列表分别使用 array.Length 和 list.Count 代替 Count()
Recommendations
推荐为你的 Visual Studio 安装 CodeMaid 和 ReSharper
使用 CodeMaid 来做代码整理，通常我会使用 CodeMaid 来自动整理代码，防止有些地方会有多余的空格，和自动清理命名空间，除此之外 CodeMaid 还有一个比较赞的功能是在使用 region 来区分代码块的时候，CodeMaid 会在 EndRegion 处增加对应的 Region 的描述信息，这样方法较长，region 较多的情况下会比较容易区分哪里是哪一部分的会比较清晰
遵循 ReSharper 的建议编写更整洁的代码，ReSharper 会提供很多实用的建议，比如使用新的 C# 语法来简化代码，移除没有使用的变量等很多很实用的建议，按照 ReSharper 的建议我们就可以比较轻松的写出比较良好的代码，有时候 ReSharper 的命名规则可能会于自己的习惯不符，可以通过定制 editorconfig 来指定命名规范
More
Resharper 也有代码整理的，不过我没用过，习惯了 CodeMaid 了，有兴趣的可以研究一下，一起交流一下哈~~
