开篇

  • 我们总是很容易就能写出满足某个特定功能的代码，却很难写出优雅代码。又最欣赏那些优雅的代码，因为优雅代码更能体现一个开发者的积累。
  • 就像写一篇散文，有的就像初学者不得其门而入，遣词造句都非常困难，然后纠纠结结，最终不了了之。或者啰哩吧嗦，看起来说了一堆，其实就像是村妇闲聊，毫无重点，不过是口水文而已。
  • 好代码应该是这样的，如涓涓细流、如同一首诗，一篇优美的故事，将作者编写代码时的情感慢慢铺垫开来，或是高潮迭起，此起彼伏，或是平铺直述，却蕴含道理。我始终相信优秀的代码是有灵魂的，代码的灵魂就是作者的逻辑思维。
  • 编写整洁代码 or 非整洁代码，就像平时生活中是否注意爱护环境的一点点小习惯，一旦坏味道代码没有及时处理，就会成为破窗效应，然后逐渐的代码越写越烂，最终这些代码要么以重构收场，要么就被抛弃。
  • 我们见过太多没有毫无质量可言的代码，许多时候开发者们由于能力原因、或者时间有限，写了许多能够满足当前工作的代码，然后就弃置高阁，不再理会。于是，代码写之前的只有自己和上帝能理解代码的意思，而写完了之后，只有上帝能懂了；还有一些开发者说：我只会写代码，不会优化代码，他们仿佛特别勤奋，每天都会比其他人都热衷于熬工时，但是写出的代码，实际上是一个个难以维护的技术债。而且许多代码的作者总喜欢找各种借口来抵赖，例如喜欢说代码出了问题都是底层框架太垃圾了、或者别人的代码封装得太差。他们总是抱怨这抱怨那，但是即便有优秀的框架、技术，就一定能写出优秀的代码么？
  • 在这里笔者列举了平时看到过一些自认为不太整洁的代码，以及与《代码整洁之道》（Clean Code · A Handbook of Agile Software Craftsmanship）一书中相对应的范例，欢迎大家一起来拍砖。

  • （经验有限，时间仓促，请轻喷。）

    一些栗子

  • 1、命名规则
    • 1.1 变量命名和方法命名

在我们刚刚开始学习写代码的古老时代，或许会有下面这种习惯。

/// <summary> /// author:zhangsan /// </summary> class ZhangsanTest {     private void TestGetData()     {         int a, b, c;     }     private int ZhangsanGet(int s1, int s2)     {         int s3 = s1 + s2;         return s3;     }      private List<string> GetData()     {         return null;     } }

这是一个喜欢用自己的姓名来命名类和方法的作者，在他的代码中，经常可以看到这样奇怪的对象定义，而且他还喜欢用a,b,c,d,e,f或者s1,s2这样的命名，仿佛他的代码自带混淆特效。这样的代码嗅起来会不会觉得充斥着奇怪的味道？
另外，有没有发现有许多开发者喜欢用 GetData() 来定义获取数据的方法？然后这个方法就成为一个万金油的方法，不管是爬虫采集、或者数据绑定，无论是 C# 写的后端或者 Java 写的后端代码，或者用 vue 写的前端代码，仿佛在任何场景、任何数据应用都可以看到这样的方法。
如果一个项目中，有十几个地方都出现了这个** GetData() **方法，那种感觉一定非常难受。

  • 1.2 Model、Dto 傻傻分不清楚

随着技能的增长，或许我们会学到一些新的代码概念，例如，Model、DTO 是经常容易弄混淆的一种概念，但是在某些代码中，出现了下面的命名方式就有点令人窒息了。

public class XXXModelDto     {         public int Id { get; set; }         public string Name { get; set; }         public string Alias { get; set; }     }

这是大概是一位对概念严重消化不良的资深开发者，居然同时把 Model 和 DTO 复用在一个对象上，
（当然，一个开发者定义变量的背后一定有他的动机）。
他到底是想要的是用来在 MVC 模式解决数据传输和对象绑定的模型对象？还是用于传输数据的 DTO 呢？
--其实他定义这个对象，是为了定义存储数据对象的实体（ Entity ）。

  • 1.3特殊情况术语和字段对照表非常重要

近年来开发者素质越来越高，所以许多优秀开发者会倾向于使用翻译软件来翻译变量名，然后用英语来命名，但是即便如此，许多政务项目总是能嗅出一些奇怪的味道。
例如前不久看到一条这样的短信：（原图已经消失）

xxx公积金中心提醒您：您于{TQSJ}日进行了{TQCZ}操作，账上剩余金额为{SYJE}元。

这是个bug将xxx公积金中心的某些秘密透露在大家面前。作为一个严谨的项目，居然使用中文首字母大写命名法，这让习惯于大驼峰、小驼峰的我看了之后尴尬癌犯了，很不舒服。但是这也是许多政务信息化项目的中字段命名的规范，而且在这种情况下，往往会输出一份非常规范的数据库字段对照表，确保中文和首字母的语义不让人产生歧义。
所以特定语境下，变量和方法本身没有严格的规定，但是一定要使用恰当的语境概念，对于这样的特定场景，尽量维护一份实时更新的术语表吧。

  • 2、状态码返回值
    • 2.1业务逻辑状态码

似乎在对外提供接口时，使用下列接口状态码是一种比较常见的惯例。提供统一格式的 code 状态码以及返回的消息和成功返回结果时的填充数据，能够让开发者高效的完成接口对接，无需关心http状态码背后的含义。

{"code":"100101","message":"success","data":{},