分析一套源代码的代码规范和风格并讨论如何改进优化代码

  工程实践选题是数据获取相关的,这里选择分析一个微信公众号爬虫的源代码。

一.源代码目录结构

  目录结构比较清晰

  1.bin存放关键代码

  

  2.docs存放说明文件,比如界面说明,安装说明,使用说明,环境说明等

  

  3.wechat这里是爬虫管理的代码,比如数量控制,链接控制

  

  4.wechatspider存放爬虫代码,url获取与解析等

  

  5.其他 一些配置文件和readme

  

二 .命名规则

  1.文件名

  可以看到是小驼峰命名法,getNewIp.py中首个单词首字母,第二个单词开始每个单词的的首字母大写

  

  2.类名

  使用了大驼峰命名法,每一个单词的首字母都大写。

  

  3.函数名

  使用了Snake Case命名法,单词中间用_分隔。这种命名法中的单词的首字母通常都是小写的,并且第一个词的第一个字母既可以是大写的又可以是小写的。

  

三.风格评价

  首先这个代码的结构是比较清晰有层次的,代码按照功能下分,结构合理。

  总体命名规则是很优秀的,三种命名法的使用条件符合通常的命名习惯。

  注释数量恰到好处,而且非常合理:  

    

  文档开头表明了作者:

  

  但是这份代码的缺点在于有些地方有的命名出现不规范,比如这个文件夹命名没有用任何方法分隔单词:

  

四.代码规范和风格的一般要求

  个人来讲,python使用的比较多,这里介绍一下Python通常的代码规范。

  事实上Python 官方给出了一种编码规范: PEP 8

  这个是PEP8的中文版:https://blog.csdn.net/ratsniper/article/details/78954852

  当然这个只是个标准而已,并没有强制要求大家都要去遵守,但好像大多数人都使用了 PEP 8 编码风格,使它已经成为了事实上的代码风格标准。这里主要介绍PEP8。

  1.文件开头注释

  使用pycharm可以导入预定义的模板。

  打开一个新建的Python文件进行编辑(F4),这个文件中默认有两行代码:作者姓名和工程名称。之所以会出现这两行代码,是因为Python文件在创建时是基于文件模板进行创建的,因此会预定义这两个变量。在settings > file and code templates > python script 选中,然后写入模板语法。效果如下:  

    

  2.空格使用

  • 总是在二元运算符两边加一个空格:赋值(=),增量赋值(+=,-=),比较(==,<,>,!=,<>,<=,>=,in,not,in,is,is not),布尔(and, or, not)。
  • 如果使用具有不同优先级的运算符,请考虑在具有最低优先级的运算符周围添加空格。有时需要通过自己来判断;但是,不要使用一个以上的空格,并且在二元运算符的两边使用相同数量的空格。

 

  3.命名方式

  以下是常见的命名方式:

  • b(单个小写字母)
  • B(单个大写字母)
  • lowercase 小写字母
  • lower_case_with_underscores 使用下划线分隔的小写字母
  • UPPERCASE 大写字母
  • UPPER_CASE_WITH_UNDERSCORES 使用下划线分隔的大写字母
  • CapitalizedWords(或者叫 CapWords,或者叫CamelCase 驼峰命名法 —— 这么命名是因为字母看上去有起伏的外观)。有时候也被称为StudlyCaps。
    注意:当在首字母大写的风格中用到缩写时,所有缩写的字母用大写,因此,HTTPServerError 比 HttpServerError 好。
  • mixedCase(不同于首字母大写,第一个单词的首字母小写)

  命名约定:

  Names to Avoid 应避免的名字

  永远不要使用字母‘l’(小写的L),‘O’(大写的O),或者‘I’(大写的I)作为单字符变量名。
  在有些字体里,这些字符无法和数字0和1区分,如果想用‘l’,用‘L’代替。

  Package and Module Names 包名和模块名

  模块应该用简短全小写的名字,如果为了提升可读性,下划线也是可以用的。Python包名也应该使用简短全小写的名字,但不建议用下划线。
  当使用C或者C++编写了一个依赖于提供高级(更面向对象)接口的Python模块的扩展模块,这个C/C++模块需要一个下划线前缀(例如:_socket)

  Class Names 类名

  类名一般使用首字母大写的约定。
  在接口被文档化并且主要被用于调用的情况下,可以使用函数的命名风格代替。
  注意,对于内置的变量命名有一个单独的约定:大部分内置变量是单个单词(或者两个单词连接在一起),首字母大写的命名法只用于异常名或者内部的常量。

  Function Names 函数名

  函数名应该小写,如果想提高可读性可以用下划线分隔。
  大小写混合仅在为了兼容原来主要以大小写混合风格的情况下使用(比如 threading.py),保持向后兼容性。

  4.PEP8检查

  可以使用PEP8检查代码是否不符合规则

  故意写几行不符合Python编码风格的代码:

import sys, os
from subprocess import Popen, PIPE

def long_function_name(
    var_one, var_two, var_three,
    var_four):
    print(var_one)

  检查是否符合编码规范:

$ pep8 --first test.py
test.py:1:11: E401 multiple imports on one line
test.py:4:1: E302 expected 2 blank lines, found 1
test.py:6:5: E125 continuation line with same indent as next logical line

  可以看到1、4、6行代码不符合规范

  还可以输出不符合规范的代码和原因:

$ pep8 --show-source --show-pep8 test.py

原文地址:https://www.cnblogs.com/dwtenir/p/11615399.html

时间: 2024-08-05 04:42:47

分析一套源代码的代码规范和风格并讨论如何改进优化代码的相关文章

对一套源代码的规范和风格的讨论及优化改进

我的工程实践是机器学习相关,因此我在GitHub上选了下面的源代码进行学习:https://github.com/WillKoehrsen/machine-learning-project-walkthrough 一.对源代码的分析 1.目录结构 该源代码使用Python语言,在jupyter notebook上编写.在文件目录下有auto_ml.data.deprecated.images四个文件夹和Machine Learning Project Part 1.ipynb.Machine L

Net中的代码规范工具及使用

Net中的代码规范工具及使用 https://www.cnblogs.com/selimsong/p/9209254.html 上一篇文章介绍了编码标准中一些常用的工具,本篇就具体来介绍如何使用它们来完成代码管理. 本文主要内容有: Roslyn简介 开发基于Roslyn的代码分析器 常用的基于Roslyn的代码分析器 在.Net Framework项目中使用代码分析器 安装StyleCop Analyser 设置规则 将自定义的规则使用到整个解决方案 修复代码 使用StyleCop.Json

JavaScript必备:Google发布的JS代码规范(转)

[翻译]关于Google发布的JS代码规范,你需要了解什么? 翻译 | WhiteYin 译文 | https://github.com/WhiteYin/translation/issues/10 Google为了那些还不熟悉代码规范的人发布了一个JS代码规范.其中列出了编写简洁易懂的代码所应该做的最佳实践. 代码规范并不是一种编写正确JavaScript代码的规则,而是为了保持源代码编写模式一致的一种选择.对于JavaScript语言尤其如此,因为它灵活并且约束较少,允许开发者使用许多不同的

好代码是管出来的——C#的代码规范

代码是软件开发过程的产物,代码的作用是通过编译器编译后运行,达到预期的效果(功能.稳定性.安全性等等),而另外一个重要作用是给人阅读.对于机器来说只要代码正确就能够正确的运行程序,但是人不同,如果代码编写混乱就会对代码阅读造成障碍,导致代码无法维护,甚至会导致代码重构等高成本活动,所以规范代码势在必行. 本文从以下几个方面介绍代码规范以及相关工具. .Net代码规范简介 代码格式规范 命名规范 布局规范 注释规范 代码使用规范 常用的代码规范工具 小结 .Net代码规范简介 文章开始提到过代码是

作业三: 代码规范、代码复审、PSP

(1) 是否需要有代码规范         1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反对) 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规

代码规范及代码复审

1.对代码规范的讨论 编写一个程序是否需要代码规范?本人以为,规范当然得有,但也必须合理. 为什么我们需要代码规范?代码规范就是规定代码中某些格式必须遵守一定条件,比如缩进.变量命名.注释等.当制定了合理的规范后,不仅代码本身会显得美观,而且每个人都很容易读懂,代码的可维护性也大大增强.举个例子,甲程序里使用的变量名有input_msg,output_msg,decipher,每个符号之间均加了空格,而乙程序里则是随意地使用a,b,c等无意义的字母作为变量名,而且多个函数里重复使用相同名称的局部

关于是否要有代码规范的四种观点的看法

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 答:代码规范是为了统一代码的风格和形式,方便所有人理解,这实际上降低了维护和更新软件的时间好成本. 2.我是个艺术家,手艺人,我有自己的规范和原则. 答:就算自认为是艺术家,编程的艺术也不是通过一些小的规范和形式表现出来的.服从一种代码规范并不会限制一个程序员的创造力. 3.规范不能强求一律,应该允许很多例外. 答:根据某些项目的特别需要,可以有一些针对这些项目优化过的代码规范,但大部分项目应该仍然通用一种

个人博客作业2 - 代码规范讨论与个人项目代码审查

对于是否需要有代码规范,请考虑下列论点并反驳/支持: 这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 我是个艺术家,手艺人,我有自己的规范和原则. 规范不能强求一律,应该允许很多例外. 我擅长制定编码规范,你们听我的就好了. 对于论点1,我认为是不正确的.对于一个独立的开发者来说,代码风格可以完全遵从个人意愿,代码规范也没有存在的必要,强调代码规范可能睡些许降低个人的开发效率.但是现代软件工程中,一个开发团队往往少则几个人,多则数百人,一个项目需要多个人同时

(转)ios 代码规范

转自http://blog.csdn.net/pjk1129/article/details/45146955 引子 在看下面之前,大家自我检测一下自己写的代码是否规范,代码风格是否过于迥异阅读困难?可以相互阅读同伴的代码,是否存在阅读障碍? 若存在晦涩难懂的,理解成本增大的代码,说明你的团队需要自省了. 下面总结一下OC编程中的一些代码规范(苹果官方推荐的).以OC为示例,但不局限于OC,也可以被当作别的编程语言的开发规范约定(仅需要把OC特有的东西按照你所使用的语言的惯例即可) 参考资料:苹