流畅的 Python 读书笔记(一)

用了一段时间的 Python, 觉得还是有必要读一下《流畅的Python》这本书,它虽然是基于 Python 3.4 的,但 Python 自身的很多特性希望了解的更多,更深,或巩固,或扫扫死角。

对于少量属性的对象可以用 collections.namedtuple 快速构建一个类  Card = collections.namedtuple('Card', ['rank', 'suit']), 用 type(Card) 看到的就是一个  class, 第一个参数 Card 是类名,第二个参数列表里是属性名,然后用 card = Card('7', 'diamonds') 创建一个实例。PyCharm 也能正确识别出 Card 构建与使用对象时的属性 rank 和 suit.

现代从 Python 3.7 开始引入了 @dataclasses.dataclass 比 namedtuple 要方便些

@dataclasses.dataclass
class Card:
    rank: str
    suit: str = None

card = Card(rank='7', suit='diamonds')

或者用 pydantic 的 BaseModel 都比先前的 namedtuple 好用 阅读全文 >>

Go 语言新手笔记(五)

终于来到的 Go 的网络编程了,来写一个 TCP 服务端与客户端的程序。要用到 Go 语言的  net 包,是一个标准的 Listen+Accept 结构, 下面是一个简单的 TCP Server/Client 端的例子,启动了 Server 端口,可以用 telnet 去连接,也可以用 client.go 来连接 阅读全文 >>

Go 语言新手笔记(四)

学到了 Go 语言本身的语法之后,开始步入 Go 的应用部分,掌握一个语言不得不接触的就是它对文件,网络的操作。

在正式进入主题之前不得不抱怨一下 Go 的官方编码规范中的代码缩进格式。曾经 Google 出的 Java 缩进规范是用两个空格(通常是用四个空格),并且是杜绝用  Tab 进行缩进的,因为 Tab 的宽度是不很确定的。

然而 Google 建议 Go 的代码格式化工具  gofmt 却反常规的强制使用 Tab 进行缩进,而且是。本人用 IntelliJ IDEA 编写 Go, 即使在 Go 的 Code Style 中把 Use tab character 去掉也是用 Tab 缩进,原因是在 Code Style > Go 的  Other 中有项 Run gofmt [] On code reformat, 这项也不能勾选。

不明白 go fmtgofmt 为何强势而无理的用 Tab 进行缩进,看到多数地方以 8 个空格来显示一个  Tab,实在是难看,像下面这样子的 阅读全文 >>

Go 语言新手笔记(三)

终于要开始了解 Go 的结构体和接口了。Go 的结构体只是一种纯粹的数据类型,而不像 C/C++ 的结构体里还能添加方法。Go 的 struct 更像是 Python 的 dataclass, 或 Java 的 record。Go 的结构体是值类型,通过 new 函数来创建,在 C/C++ 中,只要是 new 得到的就是指针。

结构体的字段名称也可以用 _, 相当一个点位填充,字段也可以只有类型没有名称,称之为匿名字段。 阅读全文 >>

Go 语言新手笔记(二)

Go 语方的数组声明方式别具一格,把 [] 看得太重了,看下面的各种声明方式

再次强调 Go 的数组是值类型,作为函数参数传递会产生副本。避免传入数组产生副本消耗过多内存,办法是可传数组指针或用切片,切片是第一选择。

数组的大小最大为 2GB,用 ==!= 比较两个数组时它们必须类型和长度一致。 阅读全文 >>

Go 语言新手笔记(一)

Go 语言 2009 年面世,几个成功项目 Docker, Kubernetes, etcs, consul, flannel, 还有 Terraform。Go 编译运行快,听说学习也不难。

安装好 Go 后,有两个环境变量很重要, GOPATH 是工作目录,GOROOT 是 Go 的安装目录, 如 /usr/local/go。GOPATH 允许多个目录,用 : 或 ;(Windows 下) 分隔,当 GOPATH 有多个目录,go get 命令的包放在第一个目录下。

$GOPATH 目录中约定的三个子目录

  1. src: 存放 .go, .c, .h, .s 等源码文件,go run, go install 等命令也要在该目录下执行
  2. pkg: 存放编译时生成的中间文件,如 .a
  3. bin: 存放编译后的可执行文件 

Go 编程是声明了不用的全局变量是绝对的罪过,编译这一关过不了。Go 用 var 声明变量,如 var b bool = true。Go 有精确长度的丰富的基本类型,如 int8, int16, int32, int64, unit8, float32(6位精度), float64(15位精度) 等,单纯写成  int, unit 时,长度与系统有关。Go 的字符串用 UTF-8 格式编码的 Unicode 字符,每个字符对应一个 rune 类型,rune 是字符的意思,相当于 int32. 阅读全文 >>

《Practical Vim》阅读笔记 (3)

1. 学习完前面的三大模式:正常模式,插入模式和可视模式后,现在步入了命令模式。:, / 或 ?, 和 <C-r>= 分别进入到 Ex 命令,搜索和表达式,它们都被称作命令模式, 以前还常常把正常模式说成是命令模式。: 后的是 Ex 命令,是因为我们仍然沿袭了 Vim 的前身 Ex。我在 Mac 下输入命令 ex 就会看到这个

进入到 Vim 的 Ex mode, 输入 visual 命令就是正常的 Vim 界面。Vim 之于 Ex 就像 Gui 之于 Shell, Vim 的 Ex 命令可以做任何操作,见 :h ex-cmd-index

2. 命令模式在 : 提示符下输入时可以使用插入模式下的很多命令,如 <C-w>, <C-u>, <C-k>, <C-v>, <C-r>{reg}, 甚至是 <C-r>=,就是不能用 motion 命令,光标移得靠方向键

3. 在阅读本章之前对 Vi 的命令模式只能用不觉明厉来形容,它对我的贡献仅仅是 :wq 之类的,模式查找,简单替换,再就是执行一些未设置快捷键插件功能。也一直未理解替换怎么是 %s/abc/dev, 只是依葫芦画瓢,现在终于可以在本章中理解那些命令了。从中真的能体会到 Ex 命令模式的乐趣,Ex 是不会把整个文件内容显示在屏幕上的, Ex 命令通常由 范围 + 命令 组成。

:2           -- 光标跳到第一行,正常模式下可以 2G, 或 2gg
:print    -- 打印当前行的内容

范围和命令一般会写在一块,范围可借用同样意义的特殊字符,默认操作当前行,因此下面一系列的命令就好理解了 阅读全文 >>

代码整洁之道(Clean Code) 笔记(三)

第八章:边界

本章关于如何学习使用第三方组件

  1. 第三组件或框架追求普适性,而使用者则想要集中满足特定的需求
  2. 学习第三方组件首当其冲当然还是文档,其次重要的是它的单元测试,我甚至是把单元测试当作文档的一部分来看待。其实更重要的方法是学习性测试(learning tests), 通过测试来学习才是切实的体验,是一种精确的试验,我们甚至可以用自己的测试来验证第三方组件的新版本
  3. 边界上会发生有趣的事,这就要求我们对它清晰的分割和定义,以避免我们的代码过多地了解第三方组件中的特定信息,依靠你能控制的东西好过依靠你控制不了的东西,免得日后受它控制。简而言之就是尽可能隔离边界,在边界改动时只需要修改一下适配器,对的适配

第九章:单元测试

这一章我自认为是很重要的,特别是正在采用测试驱动开发/设计(TDD) 的程序员来讲。充分,良好的单元测试是保证我对生产代码大刀阔斧的关键,这也就是 TDD 的最后一个 D 又能理解了 Design 的原由

阅读全文 >>

代码整洁之道(Clean Code) 笔记(二)

第四章:注释

  1. 别给糟糕的代码加注释 -- 重新写吧
  2. 什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧,提供错误信息的注释更有破坏性
  3. 若编程语方足够有表达力,或者我们长于用这些语方来表达意图,就不那么需要注释 -- 也许根本不需要
  4. 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败
  5. 不准确的注释要比没注释坏得多。它们满口胡言。代码,只有代码能忠实的告诉你它做的事
  6. 好注释不多,如法律信息,警示等。我都不觉得 TODO 是多好的东西
  7. 大多数注释都是坏注释,甚至一些 IDE 自动生成的代码也加一堆的废话注释,分散阅读注意力。我也写过那种日志式注释,这本是版本控制系统干的事。
  8. 很奇怪 IntelliJ IDEA 还在自动为新建的类加下创建者,代码是团队共有,时间长了根本就与作者无半毛关系。我经常碰到这种写有作者的代码哭笑不得,直接把原作者改了或删了也不太好,还不如把文件删了,新建一个没有作者注释的类
  9. 直接把代码注释掉是种讨厌的做法,自己可能不会再启用,其他人以为很重要更不敢删。不用了最好果断删掉,版本控制系统会帮你记住历史。
  10. 个人认为,注释会胡说八道,产品代码和测试代码不会撒谎。有功夫写注释还不如写好测试用例,测试需要维护,它本身就是最真实的文档。

阅读全文 >>

代码整洁之道(Clean Code) 笔记(一)

第一章:整洁代码

  1. 代码即设计
  2. 童子军军规:把露营地清理得比来时还干净,签入代码前是否已做重构
  3. 你湎自行实践,且体验自己失败。你须观察他人的实践与失败
  4. 勒布朗(LeBlanc) 法则:稍后等于永不 (Later equals never)
  5. 赶上期限的唯一方法--做得快的唯一方法--就是始终尽可能保持代码整洁
  6. 缺乏“代码感”的程序员,看混乱是混乱,无处着手。有“代码感”的程序员能从混乱中看出其他的可能与变化
  7. 不好的代码引诱别人做没规矩的优化,搞出一堆混乱来
  8. 整洁的代码只做好一件事,糟糕的代码想做太多事,它意图混乱,目的含混
  9. 整洁的代码从不隐藏设计者的意图
  10. 整洁的代码只提供一种而非多种做一件事的途径
  11. 整洁的代码总是看起来像是某位特别在意它的人写的
  12. 回放我们编码过程显示,多多数时间都是在滚动屏幕,浏览其他模块
  13. 读与写花费时间的比例超过 10:1, 写新代码时,我们一直在读旧代码
  14. 编写代码的难度,取决于读周边代码的难度 阅读全文 >>