add codstyle style and memo

PegasusWang · PegasusWang · commit fb369d2bc447 · 2017-06-13T11:46:50.000+08:00
diff --git a/codingstyle/codingstyle.rst b/codingstyle/codingstyle.rst
@@ -100,6 +100,7 @@ Python有一些语法上的坑，比如默认参数只计算一次，不要使
 当你发现debug的时间甚至比写代码长很多的时候，当你发现总是返工对代码修修补补的时候，或者可尝试下TDD。
 你可以学习使用下python的unittest或者pytest等进行单元测试，以保证代码质量。个人工作经验也表明，难以测试的代码往往是设计不太好的代码。
 update: 经验表明，TDD未必是必要的，但是单元测试是很必要的。如果是新项目建议为所有的复杂函数写单元测试，为项目质量保证。大项目如果没有单元测试修改bug和重构会有很大风险。
+另外一般写测试之前先写个失败的例子，确定测试是真正运行了的，因为之前出现过乌龙，单测函数命名没有用 test 开头结果导致根本就运行这个测试用例，而先失败一次就会避免这个问题。
 下边是一些参考书籍:
 
 
@@ -132,6 +133,7 @@ update: 经验表明，TDD未必是必要的，但是单元测试是很必要的
 * 文档化。哪些东西该文档化，哪些该注释需要做好，以便新手可以尽快上手。尽量做到代码即文档，tornado的文档和代码就是典范。
 * 服务化。项目做大了以后及时拆分业务，保持单个代码仓库大小在一定规模。
 * 不要直接吞掉任何非预知错误和异常，一定要做好记录。血泪教训，使用Sentry或其他工具记录好异常发生的信息，为定位bug提供便利，web端的bug一般不好复现。
+* 墨菲定律：只要有错误发生的可能性，这种错误就一定会发生。
 * 单元测试:F.I.R.S.T原则(Fast，Independent，Repeatable，Self-Validating，Timely)
 * ......还有的大家可以自己补充。我强烈建议新手或者自学的同学看《代码大全》或者《编程匠艺》之中的任何一本，带你快速入门。当然有些东西只是建议，编程中往往没有绝对正确，只有相对更优，No Silver Bullet，大家在实践中摸索吧。
 
@@ -160,7 +162,7 @@ python代码坏味道(新手经常犯的错误)
 - 导入最好按照模块导入，使用的时候用module.func使用，防止from module import func的时候可能遇到的循环引用问题(模块设计不够合理)。
 - 变量名乱起，表意不明，推断不出类型，加重理解负担。我在想是不是动态语言用匈牙利命名法要好一些，命名尽量要可以看出类型，比如复数表示容器类型，nums，cnts等后缀表示数值(通过后缀和词性来使名称更容易被推断出来含义)。动态语言一大诟病就是容易类型出错。
 - 不遵守pep8，没有pylint检测，打开代码一堆语法警告，老子的编辑器满眼都是warnning，编辑器用不好就老老实实用pycharm，用编辑器就老老实实装好语法检测(pep8)和pylint检测插件，没有插件请考虑换一个editor。我个人的感觉就是python代码很容易写得难以维护，请务必加上pylint检测，帮助提高代码质量。还是推荐不想折腾编辑器的直接用好pycharm。
-- 没有逻辑分块，一点都不重视排版，没有美感（这个就算了），就算不限制一行超过80列，也不能写一行写几百列吧，左右转头脑瓜子疼(请不要用tab，全用空格，不要有多余空白，vim有类似插件去除无用空白的)。使用良好的分行，空格使代码更美观，逻辑更清晰。
+- 没有逻辑分块，一点都不重视排版，没有美感（这个就算了），就算不限制一行超过80列，也不能写一行写几百列吧，左右转头脑瓜子疼(请不要用tab，全用空格，不要有多余空白，vim有类似插件去除无用空白的)。使用良好的分行，空格使代码更美观，逻辑更清晰。不要添加多余的空白或者空行，vim 有一些可以去除无用空白的插件。
 - 不要一行写太多逻辑，比如嵌套的列表推导。(Raymond's rule: One logical line of code equals one sentence in English)。好的代码读起来应该和读英文差不多，从上到下知道每一步都干了什么。
 
 * `《https://docs.python.org/3/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module》 <https://docs.python.org/3/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module>`_
@@ -174,6 +176,8 @@ python代码坏味道(新手经常犯的错误)
 - 使用sentry等工具记录异常，有利于排查问题(能保存堆栈和现场信息)。切记不要轻易吞掉非预知异常，一旦出现问题不好排查，笔者之前维护的项目曾踩过坑，后来笔者引入了sentry排查问题方便很多。
 - 捕获异常是为了处理它，确定要怎么处理异常，记录待修复？流程控制？交给上一层重新抛出(raise)？预知异常直接pass？
 - 了解你所使用的类库函数会抛出哪些异常，需不需要捕获异常？自定义函数抛出的异常最好在docstring里写出来。
+- 编写异常安全的代码: 即使发生了异常，也不会发生异常情况。比如，不会在数据库插入垃圾数据，不会异常终止等。
+- 不应当处理超出必要范围的异常，完全预测发生的异常是很困难的，应该抛出给上层程序处理。
 
 
 函数相关:
@@ -188,6 +192,7 @@ python代码坏味道(新手经常犯的错误)
 - 滥用 `(*args, **kwargs)` 导致函数接口模糊，有类似接口应该明确用docstring写明需要传入什么参数，"Explicity is better than implicity"，不要为了偷懒把代码写得隐晦。请尽量使用简单参数类型并保持接口清晰。
 - 返回多个值可以使用namedtuple封装，比用下标更直观。对于可能经常需要变动的返回值，返回字典或者对象要比返回tuple容易修改。但是这种复杂的返回类型最好在docstring里注释下返回结构。
 - 减少重复代码，否则将来接口变动一旦修改就要改动很多处，尽量保持函数简短并且尽量复用。
+- 注意函数在每个返回点的结构保持一致，尤其是在多个分之有返回点的时候。
 - 接口注意几个点，是否代码易读，易用（docstring），正确工作（单元测试）。尽量接口写出来基本就能通过名称和docstring快速让别人知道怎么用的，传入哪些值，返回什么东西，会抛出什么异常。笔者维护代码最最痛苦的就是你得一行一行读代码甚至还得打断点才能搞清楚接口是做什么的(中间充斥者复杂的嵌套数据结构，只有打断点才能看出来)，十分痛苦，十分浪费时间，用python开发省的那点时间全TM用在维护和还技术债了。偷懒只能节省一个人的成本(甚至节省不了)，对项目来说是很不利的。
 
 类相关:
@@ -491,9 +496,9 @@ Docstring应该包括什么?接口易用性
 
 Code Review
 --------------------------------------
-笔者认为code review是一件非常重要的事情，可以有效防止代码腐化，同时方便同事了解业务。可以在公司搭建Phabricator（facebook在用）类似工具进行代码review。可惜小公司流程不严格，codereview总是坚持不下去，要不就是被同事吐槽总是给他挑刺。实际上如果是新手能够从code review当中快速学到很多东西，比如编程惯用法，摆脱不良编码习惯，不良设计和难以维护的代码等。review的时候对事不对人，代码如果有明显缺陷快速记录个TODO等待review后修正，以一种开放和学习的心态看待review，慢慢整个团队的实力和代码质量就会提高。review就是个互相学习进步的过程，正规的团队都应该严格遵守，而不只是走走流程。
+笔者认为code review是一件非常重要的事情，可以有效防止代码腐化，同时方便同事了解业务。可以在公司搭建Phabricator（facebook在用）gitlab 类似工具进行代码review。可惜小公司流程不严格，codereview总是坚持不下去，要不就是被同事吐槽总是给他挑刺。实际上如果是新手能够从code review当中快速学到很多东西，比如编程惯用法，摆脱不良编码习惯，不良设计和难以维护的代码等。review的时候对事不对人，代码如果有明显缺陷快速记录个TODO等待review后修正，以一种开放和学习的心态看待review，慢慢整个团队的实力和代码质量就会提高。review就是个互相学习进步的过程，正规的团队都应该严格遵守，而不只是走走流程。
 
-- 建立 review 检查表，防止不合理、过于复杂、明显缺陷、可读性差的代码。
+- 建立 review 检查表，防止不合理、过于复杂、明显缺陷、可读性差的代码。眼睛足够多，bug 无处藏。
 - 对事不对人，review 和被 review 的人都要以一种开放和学习的良好心态看待 review，共同进步。
 
 * `《https://www.kevinlondon.com/2015/05/05/code-review-best-practices.html》 <https://www.kevinlondon.com/2015/05/05/code-review-best-practices.html>`_
diff --git a/memo/memo.rst b/memo/memo.rst
@@ -234,6 +234,10 @@ Git
     git checkout -b new_branch
     git stash pop
 
+    # rename branch
+    git branch -m <oldname> <newname>
+    git branch -m <newname> # rename the current branch
+
     # 指定文件类型diff
     git diff master -- '*.c' '*.h'
     # 带有上下文的diff
@@ -295,7 +299,7 @@ vim
    :1,3norm yss"
 
    # Git 插件
-   Plugin 'tpope/vim-fugitive' # 在 vim 里执行 :Gblame 可以看到当前文件每行代码的提交人和日期，方便找人背锅或者咨询，炒鸡好用
+   Plugin 'tpope/vim-fugitive' # 在 vim 里执行 :Gblame 可以看到当前文件每行代码的提交人和日期，找人背锅或者咨询的神器
 
 * `《vim cheet sheet》 <https://vim.rtorr.com/lang/zh_cn/>`_
 
