写枚举类，哪种对齐方式比较好？

class Action(XIntegerChoices): """ 动作 枚举类 """ CREATE = 0, "创建" DELETE = 1, "删除" UPDATE = 2, "修改" RETRIEVE = 3, "查看" LIKE = 4, "点赞" FOLLOW = 5, "关注" COLLECT = 6, "收藏" REGISTER = 7, "注册" LOGIN = 8, "登录" SEND = 9, "发送" CANCEL = 10, "取消"

方式 2：

强制对齐，但是可能会不符合代码规范，会引发 PEP 8: E221 multiple spaces before operator（所以最后用 # noqa 来使 IDE 不检查，从而不飘黄）

class Action(XIntegerChoices): """ 动作 枚举类 """ CREATE = 0, "创建" # noqa DELETE = 1, "删除" # noqa UPDATE = 2, "修改" # noqa RETRIEVE = 3, "查看" # noqa LIKE = 4, "点赞" # noqa FOLLOW = 5, "关注" # noqa COLLECT = 6, "收藏" # noqa REGISTER = 7, "注册" # noqa LOGIN = 8, "登录" # noqa SEND = 9, "发送" # noqa CANCEL = 10, "取消" # noqa

noqa

枚举类

collect

31 replies 2023-07-28 10:00:11 +08:00

chaoshui

Jul 19, 2023

老老实实第一种

zqguo

Jul 19, 2023

第二种不知道有啥好？强行工整？

vicalloy

Jul 19, 2023

在 precommit 里设置代码提交前用 black 自动格式化。
没必要在这类无关紧要的地方折腾。

XueXianqi

Jul 19, 2023

@chaoshui 好嘞

XueXianqi

Jul 19, 2023

@zqguo

我是看一些第三方库的时候看到这种 “强行工整” 的枚举类写法

colorma.ansi.py 第 49 行

class AnsiFore(AnsiCodes):
BLACK = 30
RED = 31
GREEN = 32
YELLOW = 33
BLUE = 34
MAGENTA = 35
CYAN = 36
WHITE = 37
RESET = 39

（复制过来可能没对齐，可以忽略...）

然后就在想，有没有必要这样

XueXianqi

Jul 19, 2023

@vicalloy 确实，这样有点吹毛求疵了

mainjzb

Jul 19, 2023

go 会强制对齐。希望其他语言能学习。

busier

Jul 19, 2023

这样的操作，塞到数组里面不行么！！！

hello00001

Jul 19, 2023

ctrl + alt + l

asmoker

Jul 19, 2023

换 go ，go 是第二种

XueXianqi

Jul 19, 2023

@hello00001 格式化代码，肯定是默认的第一种的...

XueXianqi

Jul 19, 2023

@asmoker 对的，Go 是第二种，格式化就会直接变成第二种！

lysS

Jul 19, 2023

肯定是第二种啊

joApioVVx4M4X6Rf

Jul 19, 2023

有什么格式化方法能把代码格式化成第二种

Leviathann

Jul 19, 2023

然后新加一个名字更长的整个文件 git 全改是吧

wuwukai007

Jul 19, 2023

class Choices:
def __init__(self, value, name):
self._value = value
self._name = name

@property
def value(self):
return self._value

@property
def name(self):
return self._name

def __eq__(self, other):
return self._value == other

def __ne__(self, other):
return not self.__eq__(other)

class Action:
""" 动作枚举类 """
CREATE = Choices(0, "创建")
DELETE = Choices(1, "删除")

# 使用
x = 0

# 判断值
if x == Action.CREATE:
print("匹配创建操作")

# 获取名称
print(Action.CREATE.name)

XueXianqi

Jul 19, 2023

@v2exblog 目前我不知道，我是手动改的

XueXianqi

Jul 19, 2023

@wuwukai007
谢谢~
我也自己封装过枚举基类，康康我的这个写得怎么样：
https://gitee.com/xuexianqi/x_utils/blob/master/enum_utils/base.py

XueXianqi

Jul 19, 2023

@Leviathann 确实，方式 2 对 git 不太友好，牵一发而动全身

zqguo

Jul 19, 2023

@XueXianqi #5 个人觉得没太必要，正常写就好

ruanimal

Jul 19, 2023

话说你这个 tuple 不加括号，有点恶心

XueXianqi

Jul 19, 2023

@ruanimal
这个是参考 Django 的枚举类： https://docs.djangoproject.com/zh-hans/4.2/ref/models/fields/#enumeration-types
其他的一些枚举类也有部分是如此，是隐式的
对于新手来说确实不够友好...

apake

Jul 19, 2023

第二种看的更清楚, 更省脑子. 所以第二种.

kingcanfish

Jul 20, 2023

来写 golang 你就不会有这个烦恼了

justdoit123

Jul 20, 2023

没调教出格式化工具，就老老实实用第一种。

iosyyy

Jul 20, 2023

在这两种对齐方式中，第一种方式（方式 1 ）通常比第二种方式（方式 2 ）更受推荐，原因如下：

可读性：第一种方式允许变量名的长度自然变化，使得代码更易读和理解。当变量名长度不一致时，对齐会导致外观上不够整齐，但通常更直观和美观。

代码规范：第一种方式符合 PEP 8 代码风格指南，这是 Python 代码的官方风格指南。PEP 8 建议避免在赋值等号（在这种情况下）之前使用多个空格。虽然第二种方式尝试通过 # noqa 来忽略代码检查警告，但最好在可能的情况下避免与代码规范冲突。

可维护性：如果未来添加或修改变量，第一种方式会自动适应变化，而第二种方式可能需要手动调整对齐，如果不仔细处理可能引入错误。

一致性：第一种方式更符合典型的 Python 代码风格，遵循大多数 Python 项目中使用的标准缩进做法。

总体而言，通常更应该优先考虑可读性、可维护性和代码规范，而不是严格的对齐。第一种方式允许灵活处理变量名长度，同时提供更干净、符合标准的代码风格。

iosyyy

Jul 20, 2023

@iosyyy chatgpt

XueXianqi

Jul 20, 2023

@mistkafka 确实，一语中的，第二种得手动格式化，成本较高，git 不友好

iorilu

Jul 20, 2023 via Android

这代码是用什么框架吗

XueXianqi

Jul 20, 2023

@iorilu
这个代码不依赖于框架。
可以单独提出来用，也可以用在 Django 、Flask 、FastAPI 里面（例如 Django 的 Model 的 choices ）

这是自己封装的枚举基类：
https://gitee.com/xuexianqi/x_utils/blob/master/enum_utils/base.py

luckyc

Jul 28, 2023

何必纠结这些, IDE 说了算, 一保存就自动格了.
管你嘞