实现高内聚,低耦合、结构清晰不臃肿、可读性高、数据冗余性低、高复用、易扩展的代码,并非易事。上到设计模式,下到某个类、方法、函数的构造。在这里我分享一下我自己的代码设计、编写风格,让我们互相学习。
首先我们要以 PEP8 代码规范为标准,但也无需完全遵守。例如:一行不能超过 79 个字符等。
main()
函数if __name__ == '__main__':
#!/usr/bin/python3
# -*- coding:utf-8 -*-
# @Author: Hui
# @Desc: { 项目主入口模块 }
# @Date: 2020/05/21 13:04
def main():
print('Hello Python')
if __name__ == '__main__':
main()
main()
函数方便用于测试当前模块功能。
import
导入,避免使用 from ... import *
,因为这可能导致模块、类、变量名重复而导致错误。
我自己的 import
代码风格有两种。
根据代码的长度由短到长依次导入,import
过度到 from ... import ...
,换行分割可有可无,我是根据 from ... import ...
前面的 import
的数量和整体美观来决定要不要换行。
import os
import sys
import time
import random
import config
import pygame
import requests
import numpy as np
from PIL import Image
from threading import Thread
from datetime import datetime
分类导入,是分好类后在根据代码的长度由短到长依次导入,主要有:
# Python内置模块导入
import os
import sys
import time
import random
from threading import Thread
from datetime import datetime
# Python自建模块、第三方库导入
import config
import pygame
import requests
import numpy as np
from PIL import Image
导入顺序依次为
Python内置模块 --> Python自建模块 --> Python第三方库
根据自己的风格,导入的自建模块、Python第三方库少时可以在一起无需换行
导入的自建模块少时可以跟Python内置模块在一起,就是转换成 由短到长 的风格
导入模块代码风格无需照搬照抄地遵循,我们做任何的优化就是为了让代码更好看,结构清晰,无需刻意遵循死规则、烂规则,应该活学活用,创新变化,学习别人优秀的方案,总结出适合自己的。
例如:
假如import
导入语句比 from
导入语句更长,要遵循或者纠结 import
是要在 from
导入语句前面还是由短到长排放呢?
import numpy as np
import multiprocessing
from PIL import Image
import numpy as np
from PIL import Image
import multiprocessing
无需太过纠结、抠字眼,两种导入风格都可以。
渲染 html
页面,把 html
的存放路径总体封装到一个类里面。
class BookView(object):
"""图书模块视图类"""
# 图书首页
INDEX_VIEW = 'book/index.html'
# 图书信息页
BOOK_INFO_VIEW = 'book/book_info.html'
# 英雄信息页
HERO_INFO_VIEW = 'book/hero_info.html'
# 定义视图函数
def index(request):
"""
图书首页
"""
data = {
'content': 'hello world',
'list': list(range(1, 10)),
}
return render(request, BookView.INDEX_VIEW, data)
def show_book(request):
"""
展示图书信息界面
"""
book_list = BookInfo.objects.all()
data = {
'book': book_list
}
return render(request, BookView.BOOK_INFO_VIEW, data)
返回页面提示的错误信息,统一封装到字典中,提高代码可读性、扩展性。
初始版本
class UserView(object):
"""用户模块视图类"""
LOGIN_VIEW = 'user/login.html'
REGISTER_VIEW = 'user/register.html'
USER_CENTER_VIEW = 'user/user_center.html'
def register(request):
username = request.get('username')
password = request.get('password')
email = request.get('email')
allow = request.get('allow')
# 校验注册项是否有空值
# all()中有一个为空返回False,都有值则True
if not all([username, password, email]):
return render(request, UserView.REGISTER_VIEW, {'error_msg': '数据不完整'})
# 校验是否勾选(同意)用户协议
if allow != 'on':
return render(request, UserView.REGISTER_VIEW, {'error_msg': '请勾选用户协议'})
# 校验用户名是否重复
try
user = User.object.get(username=username)
except User.DoesNotExists:
user = None
if user:
return render(request, UserView.REGISTER_VIEW, {'error_msg': '该用户已存在'})
return render(request, 'register.html')
可以看到在返回响应数据时代码大致一样,只有提示信息不一样
return render(request, UserView.REGISTER_VIEW, {'error_msg': '数据不完整'})
return render(request, UserView.REGISTER_VIEW, {'error_msg': '请勾选用户协议'})
return render(request, UserView.REGISTER_VIEW, {'error_msg': '该用户已存在'})
因此封装后的版本
def register(request):
username = request.get('username')
password = request.get('password')
email = request.get('email')
allow = request.get('allow')
error_msg = {
'email_error': '邮箱格式不正确',
'user_exists': '该用户已存在',
'data_error': '数据不完整',
'user_protocol': '请勾选用户协议',
}
# 返回页面的数据
data = dict()
# 校验注册项是否有空值
# all()中有一个为空返回False,都有值则True
if not all([username, password, email]):
data['error_msg'] = error_msg['data_error']
# 校验是否勾选(同意)用户协议
elif allow != 'on':
data['error_msg'] = error_msg['user_protocol']
else:
# 校验用户名是否重复
user = User.object.filter(username=username)
if user:
data['error_msg'] = error_msg['user_error']
else:
pass
return render(request, UserView.REGISTER_VIEW, data)
# 校验用户名是否重复
try
user = User.object.get(username=username)
except User.DoesNotExists:
user = None
优化后
User.object.filter(username=username)
get
获取不到数据会报异常,filter则返回一个空的 query_set
查询结果集,去除了 try ... except
异常捕获。让代码结构更清晰。
我们把 if、if..
改成了 if elif else
,把 render(request, 'register.html', data)
抽到外面去了,并不需要在每一个 if
里面 return
响应。把错误信息封装在 error_msg
字典中,下次想再添加一些错误提示信息或者想修改错误提示信息可以在 error_msg
字典中添加、修改,这样易维护、扩展,也更加明确有哪些错误信息。