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

[XueXianqi]

方式 1：

• 普通的方式，但是不一定会整整齐齐（因为每个变量名长度不一定一致）

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

[chaoshui]

老老实实第一种

[zqguo]

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

[vicalloy]

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

[XueXianqi]

@chaoshui 好嘞

[XueXianqi]

@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]

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

[mainjzb]

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

[busier]

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

[hello00001]

ctrl + alt + l

[asmoker]

换 go ，go 是第二种 🤨

[XueXianqi]

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

[XueXianqi]

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

[lysS]

肯定是第二种啊

[0x0208v0]

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

[Leviathann]

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

[wuwukai007]

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]

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

[XueXianqi]

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

[XueXianqi]

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

[zqguo]

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

[ruanimal]

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

[XueXianqi]

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

[apake]

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

[kingcanfish]

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

[justdoit123]

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

[iosyyy]

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

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

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

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

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

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

[iosyyy]

@iosyyy chatgpt

[XueXianqi]

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

[iorilu]

这代码是用什么框架吗

[XueXianqi]

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

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

[l4ever]

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