Python核心技术与实战
景霄
Facebook资深工程师
立即订阅
13891 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从工程的角度深入理解Python
免费
基础篇 (14讲)
01 | 如何逐步突破,成为Python高手?
02 | Jupyter Notebook为什么是现代Python的必学技术?
03 | 列表和元组,到底用哪一个?
04 | 字典、集合,你真的了解吗?
05 | 深入浅出字符串
06 | Python “黑箱”:输入与输出
07 | 修炼基本功:条件与循环
08 | 异常处理:如何提高程序的稳定性?
09 | 不可或缺的自定义函数
10 | 简约不简单的匿名函数
11 | 面向对象(上):从生活中的类比说起
12 | 面向对象(下):如何实现一个搜索引擎?
13 | 搭建积木:Python 模块化
14 | 答疑(一):列表和元组的内部实现是怎样的?
进阶篇 (11讲)
15 | Python对象的比较、拷贝
16 | 值传递,引用传递or其他,Python里参数是如何传递的?
17 | 强大的装饰器
18 | metaclass,是潘多拉魔盒还是阿拉丁神灯?
19 | 深入理解迭代器和生成器
20 | 揭秘 Python 协程
21 | Python并发编程之Futures
22 | 并发编程之Asyncio
23 | 你真的懂Python GIL(全局解释器锁)吗?
24 | 带你解析 Python 垃圾回收机制
25 | 答疑(二):GIL与多线程是什么关系呢?
规范篇 (7讲)
26 | 活都来不及干了,还有空注意代码风格?!
27 | 学会合理分解代码,提高代码可读性
28 | 如何合理利用assert?
29 | 巧用上下文管理器和With语句精简代码
30 | 真的有必要写单元测试吗?
31 | pdb & cProfile:调试和性能分析的法宝
32 | 答疑(三):如何选择合适的异常处理方式?
量化交易实战篇 (8讲)
33 | 带你初探量化世界
免费
34 | RESTful & Socket: 搭建交易执行层核心
35 | RESTful & Socket: 行情数据对接和抓取
36 | Pandas & Numpy: 策略与回测系统
免费
37 | Kafka & ZMQ:自动化交易流水线
38 | MySQL:日志和数据存储系统
39 | Django:搭建监控平台
40 | 总结:Python中的数据结构与算法全景
技术见闻与分享 (4讲)
41 | 硅谷一线互联网公司的工作体验
42 | 细数技术研发的注意事项
加餐 | 带你上手SWIG:一份清晰好用的SWIG编程实践指南
43 | Q&A:聊一聊职业发展和选择
结束语 (1讲)
结束语 | 技术之外的几点成长建议
Python核心技术与实战
登录|注册

27 | 学会合理分解代码,提高代码可读性

景霄 2019-07-10
你好,我是景霄。今天我们不讲任何技术知识点,继续来一起聊聊代码哲学。
有句话说得好,好的代码本身就是一份文档。同样功能的一份程序,一个组件,一套系统,让不同的人来写,写出来的代码却是千差万别。
有些人的设计风格和代码风格犹如热刀切黄油,从顶层到底层的代码看下来酣畅淋漓,注释详尽而又精简;深入到细节代码,无需注释也能理解清清楚楚。
而有些人,代码勉勉强强能跑起来,遇到稍微复杂的情况可能就会出 bug;深入到代码中 debug,则发现处处都是魔术数、函数堆在一起。一个文件上千行,设计模式又是混淆不堪,让人实在很难阅读,更别提修改和迭代开发。
Guido van Rossum(吉多·范罗苏姆,Python 创始人 )说过,代码的阅读频率远高于编写代码的频率。毕竟,即使是在编写代码的时候,你也需要对代码进行反复阅读和调试,来确认代码能够按照期望运行。
话不多说,进入正题。

PEP 8 规范

上节课我们简单提起过 PEP 8 ,今天我们继续来详细解读。
PEP 是 Python Enhancement Proposal 的缩写,翻译过来叫“Python 增强规范”。正如我们写文章,会有句式、标点、段落格式、开头缩进等标准的规范一样,Python 书写自然也有一套较为官方的规范。PEP 8 就是这样一种规范,它存在的意义,就是让 Python 更易阅读,换句话,增强代码可读性。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Python核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(27)

  • helloworld
    我的总结

    缩进规范:
    1. 使用四空格缩进
    2. 每行最大长度79个字符

    空行规范:
    1. 全局的(文件级别的)类和全局的函数上方要有两个空行
    2. 类中的函数上方要有一个空行
    3. 函数内部不同意群的代码块之前要有一个空行
    4. 不要把多行语句合并为一行(即不要使用分号分隔多条语句)
    5. 当使用控制语句if/while/for时,即使执行语句只有一行命令,也需要另起一行
    6. 代码文件尾部有且只有一个空行

    空格规范:
    1. 函数的参数之间要有一个空格
    2. 列表、元组、字典的元素之间要有一个空格
    3. 字典的冒号之后要有一个空格
    4. 使用#注释的话,#后要有一个空格
    5. 操作符(例如+,-,*,/,&,|,=,==,!=)两边都要有一个空格,不过括号(包括小括号、中括号和大括号)内的两端不需要空格

    换行规范:
    1. 一般我们通过代码逻辑拆分等手段来控制每行的最大长度不超过79个字符,但有些时候单行代码还是不可避免的会超过这个限制,这个时候就需要通过换行来解决问题了。
    2. 两种实现换行的方法:
    第一种,通过小括号进行封装,此时虽然跨行,但是仍处于一个逻辑引用之下。比如函数参数列表的场景、过长的运算语句场景
    第二种,直接通过换行符(\)实现

    文档规范:
    1. 所有import尽量放在代码文件的头部位置
    2. 每行import只导入一个对象
    3. 当我们使用from xxx import xxx时,import后面跟着的对象要是一个package(包对应代码目录)或者module(模块对应代码文件),不要是一个类或者一个函数

    注释规范:
    1. 代码块注释,在代码块上一行的相同缩进处以 # 开始书写注释
    2. 代码行注释,在代码行的尾部跟2个空格,然后以 # 开始书写注释,行注释尽量少写
    3. 英文注释开头要大写,结尾要写标点符号,避免语法错误和逻辑错误,中文注释也是相同要求
    4. 改动代码逻辑时,一定要及时更新相关的注释

    文档描述规范:
     三个双引号开始、三个双引号结尾;
     首先用一句话简单说明这个函数做什么,然后跟一段话来详细解释;
    再往后是参数列表、参数格式、返回值格式的描述。

    命名规范:
    1. 变量名,要全部小写,多个词通过下划线连接,可以使用单字符变量名的场景,比如for i in range(n)这种变量没有实际意义的情况
    2. 类的私有变量名,变量名前需要加2个下划线
    3. 常量名,要全部大写,多个词通过下划线连接
    4. 函数名,要全部小写,多个词通过下划线连接
    5. 类名,要求驼峰形式,即单词首字母大写,多个词的话,每个词首字母大写然后直接拼接
    6. 命名需要做到名如其意,不要吝啬名字的长度

    代码分解技巧:
    1. 不写重复代码,重复代码可以通过使用条件、循环、函数和类来解决
    2. 减少迭代层数,让代码扁平化
    3. 函数拆分,函数的粒度尽可能细,也就是一个函数不要做太多事情
    4. 类的拆分,如果一个类中有多个属性描述的是同一类事物,就可以把这些属性拆分出来新建一个单独的类
    5. 模块化,若项目偏大,要为不同功能模块创建独立的目录或文件,通过import互相关联

    作者回复: 很棒

    2019-07-11
    2
    34
  • lipan
    还记得刚开始写第一个iOS项目的时候,一个文件几千行代码。

    业务和逻辑没有分层设计的思想,全部混合在一个文件里,虽然勉强实现了功能,但是后期代码没法改,连我自已都看不懂了,遑论接盘者。

    后来在做新浪微博登录授权的时候,看了一下微博oAuth的授权流程,顿时大开眼界。后来又看了一些苹果给的开发例子,才开始有了代码的分层设计和想法,然后才开始学习iOS的MVC和MVVM的设计架构,代码算是勉强看得下去。

    所以我觉得如果要提高代码水平,除了动手实战以外,还要多观摹和学习大神的项目代码。

    看到老师能够把Python知识给我们讲解深入浅出,举重若轻,完全符合我心目中的大神风范。

    因此,希望老师可以给我们分享一些Python的小、中型的项目或Demo(关于爬虫、机器学习、深度学习、自动运营、量化分析或是其它有趣的Python做的小工具都可以)。以供我们观摹学习。谢谢。

    作者回复: 👍

    2019-07-11
    8
  • 夜路破晓
    听很多程序员讲过,开始他们的关注点大多数是先写出能跑起来的代码,后期当优化成为他们的瓶颈和需求时再来关注代码规范之类的问题。
    对于初学者而言,想要实现弯道超车,就需要下大力气把基础夯实,而代码规范正是其中重要的一项。

    不可否认,担心学了半天能写漂亮但跑不起来代码的大有人在。如何权衡呢?
    分享一个认知:写漂亮代码与写能跑起来的代码之间不存在因果关系,两者都是你需要花费时间精力学习的内容。
    越早认识到这一点,越能合理而高效地安排自己的学习计划。

    作者回复: 万事万物都有个度在里面。

    在公司写业务逻辑,有规定完成时间的前提下,很容易写出不规范,不优雅的代码,长期以往,能力自然得不到更多的锻炼。自己学习的时候,就一定不要为了贪图快,而是更多地去进行思考,之后再写代码,多花时间在思考上,而不是打字上。

    2019-07-10
    1
    6
  • new
    如果代码逻辑清晰,加上注释是锦上添花的事,相对写代码和读代码,程序员更愿意自己写代码,而在项目中又必须要读代码,因此代码注释真的很重要,特别是那些逻辑复杂还掺杂部分业务的代码逻辑,如果不加注释几乎不可能有人理解,但是问题来了,如果后来的程序员把最初编写代码的人的代码修改了,但是注释却不更新就会对公司其他人产生重大影响相当于埋了雷,比如你用128个标识位分别表示128个探头启停信号,而在硬件升级过程中探头数量减少了4个探头,原始注释可能是描述128个探头信号启停等信息,而第二个程序员在升级修改时直接修改了循环计数变量为124,常量128未修改,注释也没有改,后又新来的程序员以为程序存在bug,把循环次数重新改回了常量定义128,导致4个探头怎么也读取不到信号,测试n长时间,最后查到硬件才明白是根本没有那4个探头

    作者回复: 👍

    2019-07-10
    1
    3
  • Leon📷
    大量if else嵌套我接盘过这类代码,我觉得有两个原因造成的,第一就是开发者自己逻辑不清晰,想到哪写到哪 第二 就是懒,赶紧把泥巴墙糊完去结工钱的感觉,这是对项目的极度不负责任,也是对自己的不负责任,坏的习惯养成了就很难改掉了
    2019-11-12
    1
  • 吴月月鸟
    写的代码没写注释,当初自己一行一行码的代码,过段时间自己都不认识了。
    2019-07-11
    1
  • JackDong
    老师,我看之前的文章有个疑问,就是说列表在扩容的时候如果遇上空间被占用,需要重新复制到一块新的地址时。它的id会变么?
    2019-07-10
    1
  • Paul Shan
    代码拆分是让代码清晰的关键,毕竟很少有特别大部头的代码是可读的。
    2019-11-22
  • Paul Shan
    代码规范应该由机器自动完成,当一个程序员使用多种语言的时候,每种语言的规范其实不一样,例如命名规则,如果都有机器自动完成检查,事半功倍。
    2019-11-22
  • zxguan
    有推荐的“目录结构规范”么? 谢谢
    2019-10-29
  • 自由民
    初学时很多bug找了半天不知道问题在哪,最后发现是少加1或者多加1这类的,或者少写一个=。而之所以看不出来,跟代码写了并拢在一起,没有适当的空格很有关系。那时又是初学,很打击信心。后来就严格按规范写了。
    2019-10-19
  • 丁丁历险记
    重构,改善代码即有设计,里面有大量拆解套路,例如代码意图和代码实现分离。
    2019-10-07
  • Geek_54edc1
    现在越来越觉得给变量、函数起名字是个大学问~~~~,最重要的是不能有歧义!!!!
    2019-09-26
  • cyz
    值得反复阅读
    2019-09-18
  • Geek_8716eb
    定期观摩一些好的开源项目,或者组内优秀的项目代码块,提高一下自己的代码品味。
    2019-09-01
  • 竹篮打水
    最后一个示例、class Job的self.job_description = description前面少了一个job_、应该是self.job_description = job_description。
    2019-08-07
  • 🍐
    找数组中最小数那个,老师的代码跑出来结果好像有问题啊
    2019-07-31
  • Hector
    pytorch的源码注释很优秀
    2019-07-16
  • 大C
    用了uuid的库,自动生成uuid。然后有一个变量名起成了uuid。。。。
    2019-07-15
  • Geek_d848f7
    出现过命名和内置模块一样的情况,结果调用内置模块时,报错或者不起作用
    2019-07-15
收起评论
27
返回
顶部