干净的代码很重要，干净的代码可以帮助其他人理解您的代码，但是干净的代码也很主观！我想分享给您我的看法，它是由多年的开发人员领导技术团队领导经验和团队合作而成。
干净的代码可以帮助人们理解代码。根据大多数开发人员的意见，您的代码结构越多（不是一地鸡毛一盘散沙），其他开发人员就越可能理解您的代码！
干净代码的一些原则是：
- 使用有意义且易于理解的标识符
- 使用函数并使其尽可能短
- 如果您的代码易于阅读，大部分时间您不需要注释
- 不要重复自己（DRY）
- 保持简单，愚蠢！(KISS)
- 过早的优化是万恶之源
- 告诉一声即可，不要索要（TDA：Tell, dont ask ）
- Demeter定理
- 关注点分离
- 单一责任原则（SRP）
- 开放封闭原则（OCP）
- Liskov替代原则（LSP）
- 接口隔离原则（ISP）
- 依赖倒置原则（DIP）
简洁的代码可帮助他人理解您的代码，每个开发人员都有自己的编码风格。他们喜欢某些东西，而他们不喜欢。他们喜欢以某种方式做事，因为这对他们最有效。
通过利用众所周知的原则并将其整合到我们自己的工作中，我们为其他意识到这些原则的人打开了可能性，使他们更容易地进入我们的代码库。
就像使用标准化技术一样！以Dockerfile为例。如今，语法大多已标准化。如果您可以编写一个可与Docker一起使用的Dockerfile，则还可以使用podman创建一个容器，因为大多数命令都是标准化的！
现在将其转移到我们编写代码的方式。您肯定可以想象，当许多开发人员利用相同的原理来编写和构建其代码时，理解会变得更加容易！
干净的代码是主观的，如上所示，干净的代码利用了许多原理。但是原则就是它们的名字。在某些情况下，几乎不可能给所有人一个严格的方法来做事情。这导致对干净代码的许多解释。
以可读的标识符为例。函数getDogs（ctx）{[...]}与函数getDogs（context）{[...]}对比，您能确定哪个更易读吗？如果您问5个开发人员，您会收到10个不同的答案。这是主观部分的一个例子。
对于某些开发人员而言，缩写ctx是众所周知的，对于其他开发人员而言则并非如此，他们更喜欢标识符上下文。方法的长度，接口太多或不足是同样的。
与同事讨论干净的代码，并将每条原则转化为团队的特定规则集。以团队的方式共同决定代码的外观。再次讨论是否有人改变主意。
建立一套所有团队成员都可以同意的规则和最佳实践。这样，接受度就会大大提高，人们将更愿意遵循给定的规则。尽可能利用自动化，如linter等！
只要根据您的团队的决定来配置工具，就无需进行人工工作或进行冗长的讨论。如果工具说您做错了，则必须进行调整。如果您认为该规则很糟糕，请作为一个团队进行讨论！
对于干净代码，许多初学者和/或新手程序员往往不知所措，这是可以理解的。他们不仅必须学习编写代码，而且每个人都要求他们正确地编写代码。
首先，最好将重点放在基础知识上，然后在基础坚实的情况下尝试使用简洁干净的代码。