Flake8 Rules

The standardization of writing in programming languages is very important, good programming practices can prevent a lot of bugs.

Python is a language with more freely formatting, so it’s important to follow the famous flake8 rules.

The following article explains in detail every rule of the Flake8, it’s worth learning.

The Big Ol’ List of Rules

I like Pycharm because it can automate monitoring of these rules, so we can write the elegant Python program.

Pycharm 2017.3 发布

我始终认为用敏捷开发的方式持续升级是一件很恐怖的事情,因为不断的提升功能和性能同时又和市场贴近,产品就会非常有竞争力。

Pycharm 就是这样一款产品。Pycharm 2017.3 今天正式发布了,这次主要提升的是各类性能、科学计算、Rest 调试工具等,详细情况可以到 JetBrains 官网查看。

https://www.jetbrains.com/pycharm/whatsnew/#v2017-3-python

最近开始尝试用 Go 语言来进行服务端的测试,我始终不太喜欢 Java 的啰嗦。JetBrains 的 Go 语言工具目前还是在测试中,希望能够尽快提升功能和稳定性,现在这样一个月一个的早期测试版本使用起来也不是很方便。


I always think it’s a wonderful thing to keep upgrades in an agile way, because of the continuous promotion of features and performance and the close to the market, the product will be very competitive.

Pycharm is such a product. Pycharm 2017.3 was officially released today. The main promotion is all kinds of performance improved, scientific computing, Rest debugging tools, and so on. The details can be examined on the JetBrains website.

https://www.jetbrains.com/pycharm/whatsnew/#v2017-3-python

Recently I started trying to test writing server with the Go language. I don’t love Java verbose. JetBrains’s Go language tool is still in the early beta test, hope to improve the function and stability as soon as possible. It is not very convenient to use an early test version that I need update every month.

 

PyCharm 开发环境中出现中文显示不正常怎么办

说明一下,不是说python程序代码中文显示为,也不是说python程序怎么输出中文,而是 pycharm,这个开发神器有时候也会莫名其妙的让开发环境 ide 里面的中文显示不正常,比如中文的文件名,或者 git 提交的中文注释,都变成了一个个框。

我再mac 下用新版本的 pycharm 5.0.3 ,一切正常,但是到了windows 下,就出现了上面说的问题。解决方法就是到 Settings-Appearance,下面有一个字体选择,修改为 微软雅黑,肯定就没事了,ide 会提示这是覆盖了默认的字体什么的,也不用管了。

好了,中文文件名等都正常了。和 utf-8 之类没有关系。

python中使用单元测试和代码覆盖率测试的一个小例子

因为大数据的关系,接触python,的确很棒的语言,简洁优雅。

今天下午给同事说要注意单元测试和代码覆盖率,于是随手举例,没想到演砸了,继而研究了一下,分享之。

首先进行的 run with coverrage 的结果,运行的是一个单元测试文件。(我们用的是pycharm)
可以看到,主程序 r2c1_mian.py 的覆盖率在 94%,还是很不错的。(当然程序相对简单)

屏幕快照 2015-12-09 17.11.28

看下面的这个函数,检查一个整数或者单词,设计上是2,然后前面单元测试也通过了,我于是说只要修改为3,那么这些业务逻辑就不对了,再跑单元测试就应该会有通不过的情况。

屏幕快照 2015-12-09 17.13.04

屏幕快照 2015-12-09 17.14.53

结果没想到,单元测试通过了,也就是这个业务逻辑是有问题的(代码没有贴全,后面会说到),因为单元测试中是有针对这类情况的断言测试的。

屏幕快照 2015-12-09 17.14.16

注意上面代码的第一个代码和下面的代码,左边都有绿色和红色,这就是前面覆盖率运行时候的标记,绿色表示单元测试执行到的代码,红色表示没有执行到。

上面的那个代码左边红色的恰恰是返回False的代码在单元测试中没有被测试到(这个test case是有的,其实是被其他代码执行到而跳过了),下面的代码是上面代码调用到的,从左边红颜色可以看到很明显,有一个内部的返回True和一个返回False都没有被测试到,所以需要修改单元测试代码,来保证测试覆盖率。

屏幕快照 2015-12-09 17.34.53

整个业务逻辑的修改过程不详细说了,后来发现不是单元测试用例问题,而是业务逻辑有问题,所以这部分代码重构了一下,再进行一次单元测试代码覆盖率测试,可以看到同样的代码左边全部是绿色了,也就是至少单元测试的代码都覆盖到了。(这样就比较心安)

屏幕快照 2015-12-09 18.36.24

然后运行刚才修改为3的代码部分(可以理解为修改错了,或者不小心改错了的模拟,如下单元测试告诉我们有一个test case无法通过,看列出的代码也的确是我们期望的错误。

屏幕快照 2015-12-09 18.40.14

最后是代码比较,为了这个本来想说明单元测试好处而做得演示结果真的发现错误然后重构了这部分逻辑的调整,用代码比较工具呈现的情况:

屏幕快照 2015-12-09 18.41.52

对于一个健壮的程序来说,单元测试还是需要的,对于单元测试来说,足够的test case很重要,而对于需要测试的代码的覆盖率检查也不能忽视。