推荐学习书目 Learn Python the Hard Way Python Sites PyPI - Python Package Index http://diveintopython.org/toc/index.html Pocoo 值得关注的项目 PyPy Celery Jinja2 Read the Docs gevent pyenv virtualenv Stackless Python Beautiful Soup 结巴中文分词 Green Unicorn Sentry Shovel Pyflakes pytest Python 编程 pep8 Checker Styles PEP 8 Google Python Style Guide Code Style from The Hitchhiker's Guide
这是一个创建于 813 天前的主题，其中的信息可能已经有所发展或是发生改变。
方式 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  | 1 chaoshui 2023-07-19 14:30:44 +08:00  1 老老实实第一种 |
 | 2 zqguo 2023-07-19 14:47:14 +08:00 第二种不知道有啥好？强行工整？ |
 | 3 vicalloy 2023-07-19 14:47:24 +08:00 2 在 precommit 里设置代码提交前用 black 自动格式化。 没必要在这类无关紧要的地方折腾。 |
 | 5 XueXianqi OP @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 （复制过来可能没对齐，可以忽略...） 然后就在想，有没有必要这样 |
 | 7 mainjzb 2023-07-19 15:03:37 +08:00 go 会强制对齐。希望其他语言能学习。 |
 | 8 busier 2023-07-19 15:10:32 +08:00 这样的操作，塞到数组里面不行么！！！ |
 | 9 hello00001 2023-07-19 15:13:41 +08:00 ctrl + alt + l |
 | 10 asmoker 2023-07-19 15:23:03 +08:00 换 go ，go 是第二种 |
| 11 XueXianqi OP @hello00001 格式化代码，肯定是默认的第一种的... |
 | 13 lysS 2023-07-19 15:24:38 +08:00 肯定是第二种啊 |
 | 14 joApioVVx4M4X6Rf 2023-07-19 15:39:44 +08:00 有什么格式化方法能把代码格式化成第二种 |
 | 15 Leviathann 2023-07-19 15:48:12 +08:00 然后新加一个名字更长的整个文件 git 全改是吧 |
 | 16 wuwukai007 2023-07-19 16:00:25 +08:00 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) |
| 18 XueXianqi OP @wuwukai007 谢谢~ 我也自己封装过枚举基类，康康我的这个写得怎么样： https://gitee.com/xuexianqi/x_utils/blob/master/enum_utils/base.py |
| 19 XueXianqi OP @Leviathann 确实，方式 2 对 git 不太友好，牵一发而动全身 |
 | 21 ruanimal 2023-07-19 17:21:16 +08:00 话说你这个 tuple 不加括号，有点恶心 |
| 22 XueXianqi OP @ruanimal 这个是参考 Django 的枚举类： https://docs.djangoproject.com/zh-hans/4.2/ref/models/fields/#enumeration-types 其他的一些枚举类也有部分是如此，是隐式的 对于新手来说确实不够友好... |
 | 23 apake 2023-07-19 19:15:44 +08:00 第二种看的更清楚, 更省脑子. 所以第二种. |
 | 24 kingcanfish 2023-07-20 00:42:26 +08:00 来写 golang 你就不会有这个烦恼了 |
 | 25 justdoit123 2023-07-20 10:38:03 +08:00 没调教出格式化工具，就老老实实用第一种。 |
 | 26 iosyyy 2023-07-20 11:16:21 +08:00 在这两种对齐方式中，第一种方式（方式 1 ）通常比第二种方式（方式 2 ）更受推荐，原因如下： 可读性：第一种方式允许变量名的长度自然变化，使得代码更易读和理解。当变量名长度不一致时，对齐会导致外观上不够整齐，但通常更直观和美观。 代码规范：第一种方式符合 PEP 8 代码风格指南，这是 Python 代码的官方风格指南。PEP 8 建议避免在赋值等号（在这种情况下）之前使用多个空格。虽然第二种方式尝试通过 # noqa 来忽略代码检查警告，但最好在可能的情况下避免与代码规范冲突。 可维护性：如果未来添加或修改变量，第一种方式会自动适应变化，而第二种方式可能需要手动调整对齐，如果不仔细处理可能引入错误。 一致性：第一种方式更符合典型的 Python 代码风格，遵循大多数 Python 项目中使用的标准缩进做法。 总体而言，通常更应该优先考虑可读性、可维护性和代码规范，而不是严格的对齐。第一种方式允许灵活处理变量名长度，同时提供更干净、符合标准的代码风格。 |
 | 29 iorilu 2023-07-20 13:24:20 +08:00 via Android 这代码是用什么框架吗 |
| 30 XueXianqi OP @iorilu 这个代码不依赖于框架。 可以单独提出来用，也可以用在 Django 、Flask 、FastAPI 里面（例如 Django 的 Model 的 choices ） 这是自己封装的枚举基类： https://gitee.com/xuexianqi/x_utils/blob/master/enum_utils/base.py |
 | 31 luckyc 2023-07-28 10:00:11 +08:00 何必纠结这些, IDE 说了算, 一保存就自动格了. 管你嘞 |
Select Language