推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 2132 天前的主题，其中的信息可能已经有所发展或是发生改变。
想请问 v2er 知不知道 python 有没有类似这样的开发规范手册? 里面包含了开发技巧,和大企业里面的规约 之类的.
楼主自己读过 java 的开发手册, 没事就会翻一翻,像参考书一样很有用, 如果 python 也有就好了
 |
1
kmer 2019-01-07 15:53:18 +08:00
|
 |
2
haoz1w0w 2019-01-07 15:59:10 +08:00
有人会按照那个开发规范开发么。。。
|
 |
3
likuku 2019-01-07 16:05:24 +08:00
|
 |
4
lihongjie0209 2019-01-07 16:13:09 +08:00
Python 社区要的是自由和优雅, 手册这么死板的东西是不可能的
|
 |
5
PhpBestRubbish 2019-01-07 16:24:45 +08:00
自由和优雅，对于企业级多人开发来说不是灾难吗？
|
 |
6
alexmy 2019-01-07 16:50:27 +08:00
我欲成仙，我只想写 a,b,c,d 的变量名。
|
 |
7
Raisu 2019-01-07 16:54:02 +08:00
用 pycharm 的话，默认会有 pep-0008 风格提示的，只要没有提醒那应该就 OK 了
|
 |
8
qq976739120 2019-01-07 17:19:18 +08:00
忘掉所有乱七八糟的语法糖
|
 |
9
longaiwp 2019-01-07 18:30:03 +08:00  1
如果选择忘掉乱七八糟的语法糖，那我为什么不用 Jawa ？
|
 |
10
enchilada2020 2019-01-07 18:39:52 +08:00 via Android
不懂 Java 也不懂 Python 只写过几行 hello world 级别的垃圾代码
感觉 Java 好啰嗦 Python 又不好好说话 |
 |
11
tiedan 2019-01-07 19:20:36 +08:00
用 pep8 作为参考就行了
|
 |
12
chroming 2019-01-07 19:52:05 +08:00
就谷歌那个吧
|
 |
13
shmilypeter 2019-01-07 21:58:47 +08:00
那不是开发手册，那是代码规范
|
 |
15
gitandgit 2019-01-07 23:30:43 +08:00 via iPad
|
 |
16
KgM4gLtF0shViDH3 2019-01-08 08:34:27 +08:00 via iPhone
自从 py 被培训班盯上之后半吊子越来越多，招人筛选难度也越来越大
|
 |
17
passerbytiny 2019-01-08 09:04:26 +08:00
作为 Java 开发，我已经很久没看过那个开发手册了。
所谓的规范，是团队合作用的，那么自然团队不同，规范也就不同。 阿里那个手册，当你在阿里，或者想去阿里的时候，才是参考手册；否则就只是个参考，不是手册。 |
 |
18
lazyfighter 2019-01-08 13:18:22 +08:00
@passerbytiny 参考也不错，小公司没有规范的遍地都是。
|
 |
19
iorilu 2019-01-18 13:55:03 +08:00
import this
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! |
Select Language