文章目录
- 软件工程学习笔记目录
- google代码规范
- 节选python来自google翻译
- 错误注释的示例
- 命名规范
- import语句的规范
- import this 源码
软件工程学习笔记目录
[https://blog.csdn.net/csdn_kou/article/details/83754356]
google代码规范
https://github.com/google/styleguide
节选python来自google翻译
2.17函数和方法装饰器
当有明显的优势时,明智地使用装饰器。避免 @staticmethod和限制使用@classmethod。
2.17.1定义
函数和方法的装饰器 (又名“ @符号”)。一个常见的装饰器@property,用于将普通方法转换为动态计算的属性。但是,装饰器语法也允许用户定义的装饰器。具体来说,对于某些功能my_decorator,这个:
class C(object):
@ my_decorator
def 方法(self):
# method body …
相当于:
class C(object):
def Methodmethod(self):
# method body …
Methodmethod = MyDecoratormy_decorator(Methodmethod)
2.17.2优点
优雅地指定方法的一些转换; 转换可能会消除一些重复的代码,强制执行不变量等。
2.17.3缺点
装饰器可以对函数的参数执行任意操作或返回值,从而导致令人惊讶的隐式行为。此外,装饰器在导入时执行。装饰器代码中的失败几乎无法从中恢复。
2.17.4决定
当有明显的优势时,明智地使用装饰器。装饰器应遵循与函数相同的导入和命名准则。装饰者pydoc应该清楚地说明该函数是一个装饰器。为装饰器编写单元测试。
避免装饰器本身的外部依赖(例如,不要依赖文件,套接字,数据库连接等),因为它们在装饰器运行时可能不可用(在导入时,可能来自pydoc或其他工具)。使用有效参数调用的装饰器应该(尽可能)保证在所有情况下都成功。
装饰器是“顶级代码”的特例 - 请参阅主题以获得更多讨论。
@staticmethod除非被强制使用以便与现有库中定义的API集成,否则切勿使用。写一个模块级函数。
使用@classmethod只写了一个名为构造函数或类特定的例程,它需要修改全局状态,如进程范围的缓存时。
错误注释的示例
命名规范
import语句的规范
- import次序:先import Python内置模块,在import第三方模块,最后import自己开发项目中的其他模块;这几种模块用空行分割开来
- 一条import只可以import一个模块
- 当从模块中import多个对象且超过一行时,使用如下断行方法:
- from module import (obj1,obj2,obj3,obj4,obj5,obj6)
- 不要使用from module import * ,除非时import常量定义模块或其它你确保不会出现命名空间冲突的模块
import this 源码
import this
python3 test.py
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea – let’s do more of those!
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm
源代码
s = """Gur Mra bs Clguba, ol Gvz CrgrefOrnhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""d = {}
for c in (65, 97):for i in range(26):d[chr(i+c)] = chr((i+13) % 26 + c)print "".join([d.get(c, c) for c in s])
网上很多人说是恶搞,这其实是凯撒密码:
字符前移13位然后模26而已