Skip to content

Navigation Menu

Sign in
Sign up
This repository was archived by the owner on Jan 6, 2023. It is now read-only.
This repository was archived by the owner on Jan 6, 2023. It is now read-only.

clean code 学习笔记 #1

Open
Open

Description

如何提高代码可读性

如何让代码更好的表达出来,此时凸显英语的重要性!!!

命名

  • 命名需要表述清晰,不能使用 I l O 1 0 等容易混淆的字母进行命名

  • 命名需要表述准确,尽可能达到 顾名思义 的效果

注释

当代码较为复杂,可以使用注释表述其意。好的命名可以达到顾名思义的效果,不值得写注释

书中推荐使用注释的几种场景:

  • 对意图的解释。 可以解释某一部分代码用来干什么

  • 阐述晦涩难明的参数或者返回值意义 。

    一般是标准库的数据类型,无法修改。如果是自定义的数据类型,建议修改命名便于理解

  • 警示其他人。 例如 修改某一行会出bug 等等警示信息

  • // Todo

参数

  • 函数参数尽量不要太多
  • 标识参数不要用布尔值。(这样还需要联系上下文理解参数意义与不同场景)

代码格式

  • 1、实体变量统一置顶

  • 2、自上而下的展示函数调用依赖顺序

    • 具体规则:被调用的函数应该放在执行调用的函数下面。
    • 表现形式:像报纸文章一样,概念先出来,然后表述大体流程,最后详细体现底层细节。
    • 优点 : 快速阅读代码文件,从前几个函数即可知要旨,不必成溺到细节

如何提高代码可用性

对象和数据结构

  • 使用抽象 : 减少代码影响

    • 具体:例如多态,调用方不需要关注具体的实现细节,只需了解该调用什么方法达到效果。

    • 推荐:设计模式 **里氏替换原则 **

      里氏替换原则: 通过抽象建立规范,具体实现在运行时在替换抽象

    • 优点:需求会变,代码也会变,可以隔离修改代码带来的影响

  • 使用封装和继承 :代码复用

错误处理

  • 程序出现逻辑错误,例如参数校验等。 一般需要通过错误码来返回。
  • 程序无法处理的错误,例如网络连接故障,文件权限等。 一般通过 panic 抛出,并捕捉其错误

单元测试

测试的目的之一就是通过实例起到文档的作用

常用模式: 构造 - 操作 - 检验 (Build - Operate - Check)

目前个人用到两种测试方法:

  • 代码覆盖测试 : 测试用例尽可能覆盖每一行代码,保障代码能运行

  • 代码场景测试 : 测试用例尽可能覆盖不同场景,保障场景都能覆盖

代码的优化

引用传递

尽量使用指针或者引用传递,减少开销。

并发

并发是一种解耦策略,将 做什么(目的) 和 何时做 (时机)分解开

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      AltStyle によって変換されたページ (->オリジナル) /