简述

对于一个已经确定的需求, 实际上, 逻辑上已经没有多少自由了(当然还是有的), 我们所享有的自由, 大致只有以下几项了
编程语言留给程序员的自由:

1. 函数的体量和位置
2. 模块/类/函数/变量的命名
3. 表达逻辑的方式

程序员可以使用这些自由做什么? 表达思想, 编程语言提供的规则, 可以让人从数学的角度解决需求, 但是, 如何优雅的解决需求, 关键在于使用好这些属于我们的自由

示例

函数名和变量名的自由

获取用户的last_name

1. 简单的逻辑表达

def a(b):
    c = b.split(‘.‘)[-1]
    return c

2. 加上业务含义

def get_last_name(full_name):
    last_name = full_name.split(‘.‘)
    return last_name

3. 因为函数名中有"last_name", 所以, 不需要在函数体内再声明一个变量去表达业务含义

def get_last_name(full_name):
    return full_name.split(‘.‘)

4. 因为这是一个"工具类"函数, 所以可以加上type hint

def get_last_name(full_name: str) -> str:
    return full_name.split(‘.‘)

ps: type hint 的好处:

1. 形参(full_name)的对象方法可以被只能提示
   

2. 使用函数的时候会提示函数接受什么类型的参数
   

3. 使用函数时, 函数返回值的对象方法也可以被提示
   

现在, 越来越多的人开始崇尚"clean code", 但是, 我们要明白"clean code"的核心思想, 就是要在编写代码的时候考虑到需要阅读代码的人的感受,
实际上, 编写代码的时候, 你手中掌握的所有自由, 都是你增强表达能力的助力, 如何运用好这些自由, 就是"clean code"的核心思想,

函数的位置和体量

同样是一个数据处理函数, 位于不同的位置, 给予使用者的含义就不同, 这一点, 在"类和方法的关系"上表现的尤为明显, 面向对象的语言, 提供了类
的概念, 类可以为我们提供代码复用策略, 类下的方法可以被继承(复用全量), 继承+覆写(局部改写后复用了其余的部分), 多继承(合并两部分的代码)等, 抛开这些不说,
类名和方法名之间本身就存在"父子关系", 我们会在使用某个类的时候, 猜测正在使用的类下具有什么方法, 也会在调整业务逻辑的时候, 猜想到要修改的逻辑位于什么位置
这些都是类名, 方法名所具有的对于表达业务逻辑的助力, 模块与模块下所归属的函数名也是同理
比如, 你熟悉了django rest 的 MVS 设计模式的话, 就很容易知道下面的场景到哪里去修改逻辑

1. 将平均分取近似值,保留两位小数(S)
2. 给予前端的json数据中增加平均分字段(这一定是一个聚合函数的返回值, 对吧?)(V)
3. 从现在开始, 要存储所有教师的生日进数据库(M)
   这些清楚的业务表述, 使得编写代码和使用代码的人之间能够达成共识, 创造出健康成长的代码

逻辑的表达方式

关于逻辑的表达方式, 实际上在需求确定之后, 留给我们的自由并不多, 下面是一个示例

class StudentView(APIView):
    def get(self, request):
        pass

关于变量名的思考

原文：https://www.cnblogs.com/imkow/p/13193635.html