Jumpserver代码规范

Jumpserver 项目规范(Draft)

语言框架

  1. Python 3.6.1 (当前最新)
  2. Django 1.11 (当前最新)
  3. Flask 0.12 Luna (当前最新)
  4. Paramiko 2.12 Coco (当前最新)

Django规范

  1. 尽量使用Class Base View编程,更少代码
  2. 使用Django Form
  3. 每个url独立命名,不要硬编码,同理static也是
  4. 数据库表名手动指定,不要使用默认
  5. 代码优雅简洁
  6. 注释明确优美
  7. 测试案例尽可能完整
  8. 尽可能利用Django造好的轮子

代码风格

Python方面大致的风格,我们采用pocoo的Style Guidance,但是有些细节部分会尽量放开 参考国内翻译

基本的代码布局

缩进

  1. Python严格采用4个空格的缩进,任何python代码都都必须遵守此规定。
  2. web部分代码(HTML, CSS, JavaScript),Node.js采用2空格缩进,同样不使用tab (\t)。 之所以与Python不同,是因为js中有大量回调式的写法,2空格可以显著降低视觉上的负担。

最大行长度

按PEP8规范,Python一般限制最大79个字符, 但是Django的命名,url等通常比较长, 而且21世纪都是宽屏了,所以我们限制最大120字符

补充说明:HTML代码不受此规范约束。

长语句缩进

编写长语句时,可以使用换行符(\)换行。在这种情况下,下一行应该与上一行的最后 一个“.”句点或“=”对齐,或者是缩进4个空格符

this_is_a_very_long(function_call, ‘with many parameters‘)     .that_returns_an_object_with_an_attribute

MyModel.query.filter(MyModel.scalar > 120)              .order_by(MyModel.name.desc())              .limit(10)

如果你使用括号“()”或花括号“{}”为长语句换行,那么下一行应与括号或花括号对齐:

this_is_a_very_long(function_call, ‘with many parameters‘,
                    23, 42, ‘and even more‘)

对于元素众多的列表或元组,在第一个“[”或“(”之后马上换行:

items = [
    ‘this is the first‘, ‘set of items‘, ‘with more items‘,
    ‘to come in this line‘, ‘like this‘
]

空行

顶层函数与类之间空两行,此外都只空一行。不要在代码中使用太多的空行来区分不同的逻辑模块。

def hello(name):
    print ‘Hello %s!‘ % name

def goodbye(name):
    print ‘See you %s.‘ % name

class MyClass(object):
    """This is a simple docstring."""

    def __init__(self, name):
        self.name = name

    def get_annoying_name(self):
        return self.name.upper() + ‘!!!!111‘

语句和表达式

一般空格规则

  1. 单目运算符与运算对象之间不空格(例如,-,~等),即使单目运算符位于括号内部也一样。
  2. 双目运算符与运算对象之间要空格。
exp = -1.05
value = (item_value / item_count) * offset / exp
value = my_list[index]
value = my_dict[‘key‘]

比较

  1. 任意类型之间的比较,使用“==”和“!=”。
  2. 与单例(singletons)进行比较时,使用is和is not。
  3. 永远不要与True或False进行比较(例如,不要这样写:foo == False,而应该这样写:not foo)。

否定成员关系检查

使用foo not in bar,而不是not foo in bar。

命名约定

  1. 类名称:采用骆驼拼写法(CamelCase),首字母缩略词保持大写不变(HTTPWriter,而不是HttpWriter)。
  2. 变量名:小写_以及_下划线(lowercase_with_underscores)。
  3. 方法与函数名:小写_以及_下划线(lowercase_with_underscores)。
  4. 常量:大写_以及_下划线(UPPERCASE_WITH_UNDERSCORES)。
  5. 预编译的正则表达式:name_re。
  6. 受保护的元素以一个下划线为前缀。双下划线前缀只有定义混入类(mixin classes)时才使用。
  7. 如果使用关键词(keywords)作为类名称,应在名称后添加后置下划线(trailing underscore)。 允许与内建变量重名,不要在变量名后添加下划线进行区分。如果函数需要访问重名的内建变量,请将内建变量重新绑定为其他名称。
  8. 命名要有寓意, 不使用拼音,不使用无意义简单字母命名 (循环中计数例外 for i in)
  9. 命名缩写要谨慎, 尽量是大家认可的缩写

函数和方法的参数:

  1. 类方法:cls为第一个参数。
  2. 实例方法:self为第一个参数。
  3. property函数中使用匿名函数(lambdas)时,匿名函数的第一个参数可以用x替代, 例如:display_name = property(lambda x: x.real_name or x.username)。

文档注释(Docstring,即各方法,类的说明文档注释)

所有文档字符串均以reStructuredText格式编写,方便Sphinx处理。文档字符串的行数不同,布局也不一样。 如果只有一行,代表字符串结束的三个引号与代表字符串开始的三个引号在同一行。 如果为多行,文档字符串中的文本紧接着代表字符串开始的三个引号编写,代表字符串结束的三个引号则自己独立成一行。 (有能力尽可能用英文, 否则请中文优雅注释)

def foo():
    """This is a simple docstring."""

def bar():
    """This is a longer docstring with so much information in there
    that it spans three lines.  In this case, the closing triple quote
    is on its own line.
    """

文档字符串应分成简短摘要(尽量一行)和详细介绍。如果必要的话,摘要与详细介绍之间空一行。

模块头部

模块文件的头部包含有utf-8编码声明(如果模块中使用了非ASCII编码的字符,建议进行声明),以及标准的文档字符串。

# -*- coding: utf-8 -*-
"""
    package.module
    ~~~~~~~~~~~~~~

    A brief description goes here.

    :copyright: (c) YEAR by AUTHOR.
    :license: LICENSE_NAME, see LICENSE_FILE for more details.
"""

注释(comment)

注释的规范与文档字符串编写规范类似。二者均以reStructuredText格式编写。 如果使用注释来编写类属性的文档,请在#符号后添加一个冒号":"。 (有能力尽可能用英文, 否则请中文优雅注释)

class User(object):
    #: the name of the user as unicode string
    name = Column(String)
    #: the sha1 hash of the password + inline salt
    pw_hash = Column(String)
时间: 2024-10-11 17:49:45

Jumpserver代码规范的相关文章

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

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

两人合作之代码规范

代码规范 现代软件经过几十年的发展,一个软件由一个人单枪匹马完成,已经很少见了,软件都是在相互合作中完成的.合作的最小单位是两个人,两个工程师在一起,做的最多的事情就是"看代码",每个人都能看"比人的代码",并且发表意见.但是每个人对于什么是"好"的代码规范未必认同,这时我们有必要给出一个基准线-----什么是好的代码规范和设计规范. 1,写干净整洁的代码 1.1 代码格式化,包括多级代码缩进.大括号(比如C系代码),为了提高代码的美观型和易读性

代码规范的重要性

一个规范的代码,通常能起到事半功倍的作用: 一.规范的代码可以促进团队合作 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉.显然的,规范的代码在团队的合作开发中是非常有益而且必要的. 二.规范

最详细的 Swift 代码规范指南

1. 代码格式 1.1 使用四个空格进行缩进. 1.2 每行最多160个字符,这样可以避免一行过长. (Xcode->Preferences->Text Editing->Page guide at column: 设置成160即可) 1.3 确保每个文件结尾都有空白行. 1.4 确保每行都不以空白字符作为结尾 (Xcode->Preferences->Text Editing->Automatically trim trailing whitespace + Incl

项目经理的管理技巧-代码规范

一.系统里面存在的糟糕代码情况有: 1. 代码规范,命名规范和注释 2. 公用代码的抽取和封装 3. 性能低下的代码 4. 表现层.业务层.数据持久层位置存放混乱问题 二.问题 岗位调动,接手一个新的项目组.旧项目一踏糊涂,全部无规范和设计. 组成员各做各的,毫无团队协作能力,更别说团队凝聚力.简直不能更糟糕. 新项目.新成员,新项目重新做了明确规范和框架设计,但组员很多时候不能很好的按照规范进行开发 我有强迫症  三.开始犯的错误,也是最笨的做法 定时核查,自己看到不正确代码同时指出,让开发优

软工学习笔记——代码规范

上大学以来写了这几年的代码,却一直没怎么关注过代码规范相关的问题,直到软工课上讲了之后,才开始有所顾及.上课的时候回头看看自己写过的那些代码,真是丑死了,几个月前自己写的代码现在就已经读不懂了. 看了书上的相关章节,对于我来说,我觉得我的代码主要注意这几点: 1. 少写冗余代码,已经用不到的代码段就应该删去.(我今天刚刚发现我的昆特牌Online项目中竟然还存在有两个没用的类) 2. 多利用空行来将代码小规模地分段. 3. 大段的无用代码不要一直注释着,该删就删.(我的项目里经常会有一大堆没用的

代码规范

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉. 2.我是个艺术家,手艺人,我有自己的规范和原则 每一个

作业三:代码规范

对于是否需要有代码规范,请考虑下列论点并反驳/支持: 1. 这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 对于以上观点我是反对的 .如果说这些规范都是官僚制度产生的,那么更应该一丝不苟的执行,官僚制度,往大了说是法,应该无条件执行,往小了说是规范,可以帮助我们规范在打代码时自身不好的习惯.也许在编辑代码时,会比随意敲打耽误些许时间,但在检查错误时,规矩的编排格式,可以一目了然的看到自己的错误,为自己节省了更多的时间,会提高开发效率. 2. 我是个艺术家,手

作业三 (一) :是否需要有代码规范

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