长函数调用的代码应该如何设计？ [关闭]

Question

我将在这里使用 argparse 作为示例，但我认为它适用于很多事情。考虑：

parser = argparse.ArgumentParser(description="This is a description of how this program works.")
subparsers = parser.add_subparsers(title="subcommands")
parser_sub1 = subparsers.add_parser("sub1",
                                    description="subcommand 1 does something something something")
parser_sub1.add_argument("arg1",
                         help="Arg1 does somethign something something.")

等等 20 多条丑陋的线条。

add_argument 尤其是 add_parser 行很长，主要是因为帮助/描述字符串。但我认为没有明显的方法可以干净地缩短它们。如您所见，以通常的方式在第二行缩进只会获得几个字符。将字符串拆分为多行会很快变得很尴尬。

我在通过 -m pep8 运行一些代码时遇到了这个问题，它抱怨几乎每个 add_argument 行都是 >80 个字符。根本问题似乎是到开括号的那部分行本身太长，无法在后面插入字符串，即使参数之间有断行和缩进也是如此。有几种方法可以解决这个问题：

• 排长队，忽略 pep8
• 缩进续行并忽略 pep8
• 使用非常短的变量名来保存字符（例如ps1 = parser.add_subparsers(whatever)
• 别名我可以节省更多（例如psaa = parser_sub1.add_argument为每个块）
• 制作一堆字典文字，然后用 ** 将它们解压缩到函数调用中（但我觉得使用字典文字很痛苦）
• 以不那么尴尬的格式（可能是 YAML）从外部文件中读取函数调用参数，然后解压缩（但如果不引用另一个文件，您就无法知道代码在做什么）
• ...还有什么？

是否有一种已知的有效方法来处理冗长的函数参数，这些函数参数在自然编写时会违反 80 个字符的约定？

Answer 1

这在很大程度上取决于品味和意见，但在这里，有两个！

• 很少有真正的代码坚持严格的 80 列推荐。值得避免笨拙的长线，但勉强坚持源自打孔卡的约束是愚蠢的。 PEP8 也解决了这个问题：

一些团队非常喜欢更长的线路长度。对于维护的代码 完全或主要由可以就此达成协议的团队 问题，可以将标称线长度从 80 增加到 100 字符（有效地将最大长度增加到 99 字符）

• 对于这样的事情，制作某种主要通过文字表达的数据结构，然后通过 ** args 或使用循环将其铲入配置调用中可能是最明智的。它使所有文本可读、内联并集中在一个地方，因此易于编辑。你应该能够在你的代码中间得到一个看起来有点像文档字符串的 blob。

Answer 2

x = ('string literal broken across two lines '
...  'but it works because the parens keeps them together.')
>>> x
'string literal broken across two lines but it works because the parens keeps them together.'

>>> print('If this was already in the parens of an argument list '
...       'you are already in a context where string literal '
...       'concatenation works.')
If this was already in the parens of an argument list you are already in a context where string literal concatenation works.