Skip to content

Commit 39b7989

Browse files
committed
add gitignore global
1 parent 97e9aad commit 39b7989

File tree

3 files changed

+9
-5
lines changed

3 files changed

+9
-5
lines changed

codingstyle/codingstyle.rst

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ Python的世界里你会听到这个词"Pythonic",大概就是指代码符合P
7979
8080
8181
Python有一些语法上的坑,比如默认参数只计算一次,不要使用可变类型作为默认参数等,看多了写多了就知道了。尤其是可变类型作为函数参数传入后被改变的情况(函数尽量不要有副作用,这里副作用指的就是修改了传入的可变参数的值),尤其要注意。
82-
一些参考帮助写出Pythonic的代码:
82+
一些参考帮助写出Pythonic的代码(注意pythonic 不是要你炫耀奇淫技巧,维护起来心累):
8383

8484

8585
* `《Pythonic到底是什么玩意儿?》 <http://blog.csdn.net/gzlaiyonghao/article/details/2762251>`_ 赖勇浩的博客
@@ -158,7 +158,7 @@ python代码坏味道(新手经常犯的错误)
158158
- 上来就 `from shit import *,` 为了偷懒有可能会导致同名覆盖问题,还会让开发工具找不到定义,工程上不要这么用。
159159
- 包导入顺序混乱,没有按照pep8要求,实际上rope等工具能自动帮你整理顺序,我现在就是偷懒随意写,直接让rope给我整理。(标准库,三方库,本地库,同级按照字典序,vim的话可以用rope插件自动整理顺序)
160160
- 导入最好按照模块导入,使用的时候用module.func使用,防止from module import func的时候可能遇到的循环引用问题(模块设计不够合理)。
161-
- 变量名乱起,表意不明,推断不出类型,加重理解负担。我在想是不是动态语言用匈牙利命名法要好一些,命名尽量要可以看出类型,比如复数表示容器类型,nums,cnts等后缀表示数值(通过后缀和词性来使名称更容易被推断出来含义)。动态语言一大诟病就是容易类型容易出错
161+
- 变量名乱起,表意不明,推断不出类型,加重理解负担。我在想是不是动态语言用匈牙利命名法要好一些,命名尽量要可以看出类型,比如复数表示容器类型,nums,cnts等后缀表示数值(通过后缀和词性来使名称更容易被推断出来含义)。动态语言一大诟病就是容易类型出错
162162
- 不遵守pep8,没有pylint检测,打开代码一堆语法警告,老子的编辑器满眼都是warnning,编辑器用不好就老老实实用pycharm,用编辑器就老老实实装好语法检测(pep8)和pylint检测插件,没有插件请考虑换一个editor。我个人的感觉就是python代码很容易写得难以维护,请务必加上pylint检测,帮助提高代码质量。还是推荐不想折腾编辑器的直接用好pycharm。
163163
- 没有逻辑分块,一点都不重视排版,没有美感(这个就算了),就算不限制一行超过80列,也不能写一行写几百列吧,左右转头脑瓜子疼(请不要用tab,全用空格,不要有多余空白,vim有类似插件去除无用空白的)。使用良好的分行,空格使代码更美观,逻辑更清晰。
164164
- 不要一行写太多逻辑,比如嵌套的列表推导。(Raymond's rule: One logical line of code equals one sentence in English)。好的代码读起来应该和读英文差不多,从上到下知道每一步都干了什么。
@@ -519,11 +519,12 @@ Code Review
519519
如何定位和修复 bug:复现和定位。定位需要找到 bug 出现时候的上下文信息,可以用 log,sentry 等查看。确认之后通过走查代码、断点调试等方式寻找代码逻辑错误。
520520
- 走查代码
521521
- 看日志,各种日志(logging, nginx),看 sentry 异常信息
522-
- 问同事,让同事帮忙 review 审查代码
522+
- 问同事,让同事帮忙 review 审查代码。有时候人有思维定势,你自己看不出来的别人可能一眼就看出来了。
523523
- 断点调试。看变量值。
524524
- 不要死磕,一个法子不行换一个。死磕可能会耗费太长时间并且容易进入死胡同,在一个大型复杂系统中定位 bug 原因是对技术、经验、毅力、灵感、心理素质的很大考验。
525525
- 极难排查和复现的 bug 可以无限期搁置。
526526
- 找到 bug 修复以后增加相应单元测试用例,tricky 的地方要加上注释。
527+
- bug 总结:建立错误检查表,哪些可以避免的记录下来。
527528

528529

529530
重构与维护

design/design.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1495,4 +1495,4 @@ python中的抽象基类
14951495

14961496
python中的Mixin
14971497
--------------------------------------
1498-
Mixin是为了给一个类扩充功能用的,它也没法被实例化。我们可以在Mixin类里实现一些方法给类扩充功能,合理使用mixin也能避免复杂的继承关系。你可能会问了,那为啥不直接写在类里头,比如用@staticmethod方法(我就有这个疑问)?我的理解是这样的,为了『高内聚』。如果你用过pylint检测代码,你会发现你在写类的一个方法时,如果在写一个method时没有使用到任何self里的东西,pylint会给提示『R0201 Method could be a function [pylint]』,意思是这个方法可以可以单独写成一个函数,不必要写在类里。也就是说,只有一个类里实现的方法都是使用了self里的数据时才能成为高内聚的(我不知道我这样理解对不对)。例子:flask_login插件有个UserMixin给定义的用户类实现登录功能。
1498+
Mixin是为了给一个类扩充功能用的,它也没法被实例化。我们可以在Mixin类里实现一些方法给类扩充功能,合理使用mixin也能避免复杂的继承关系。你可能会问了,那为啥不直接写在类里头,比如用@staticmethod方法(我就有这个疑问)?我的理解是这样的,为了『高内聚』。如果你用过pylint检测代码,你会发现你在写类的一个方法时,如果在写一个method时没有使用到任何self里的东西,pylint会给提示『R0201 Method could be a function [pylint]』,意思是这个方法可以可以单独写成一个函数,不必要写在类里。也就是说,只有一个类里实现的方法都是使用了self里的数据时才能成为高内聚的(我不知道我这样理解对不对)。例子:flask_login插件有个UserMixin给定义的用户类实现登录功能。关于多重继承和 mixin 在 Ruby 之父的书《松本行弘的程序世界》中有不错的科普。

memo/memo.rst

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -254,6 +254,9 @@ Git
254254
# then git push -f
255255
# git rebase --abort
256256
257+
# 全局 ignore, 对于不同编辑器协作的人比较有用
258+
git config --global core.excludesfile ~/.gitignore_global
259+
257260
258261
Git工作流
259262
------------
@@ -268,7 +271,7 @@ Git工作流
268271
git fetch origin master # fetch master
269272
git rebase origin/master #
270273
271-
# 开发完成等待合并到master
274+
# 开发完成等待合并到master,推荐使用 rebase 保持线性的提交历史
272275
git rebase -i origin/master
273276
git checkout master
274277
git merge newbranch

0 commit comments

Comments
 (0)