将长变量重新指定为本地缩写是不是不好？

Question

我更喜欢使用长标识符来保持代码语义上的清晰，但是在重复引用同一标识符的情况下，我希望它在当前范围内“让开”。以Python中的以下示例为例：

def define_many_mappings_1(self):
    self.define_bidirectional_parameter_mapping("status", "current_status")
    self.define_bidirectional_parameter_mapping("id", "unique_id")
    self.define_bidirectional_parameter_mapping("location", "coordinates")
    #etc...

假设我真的想使用这个长方法名，并且这些参数总是硬编码的。 实现1感觉不对，因为每行的大部分内容都是重复的字符。一般来说，这些行也相当长，当嵌套在类定义和/或try/except块中时，很容易超过80个字符，导致行换行很难看。让我们尝试使用for循环：

^{pr2}$

我将把所有类似的迭代技术放在实现2的保护伞下，实现2改进了将“唯一”参数与“重复”方法名分开。然而，我不喜欢这样做的效果是将参数放在传递给它们的方法之前，这是令人困惑的。我宁愿保留“动词后接直接宾语”的语法。在

我发现自己使用以下方法作为妥协：

def define_many_mappings_3(self):
    d = self.define_bidirectional_parameter_mapping
    d("status", "current_status")
    d("id", "unique_id")
    d("location", "coordinates")

在实现3中，long方法被一个非常短的“缩写”变量别名。我喜欢这种方法，因为它可以立即识别为一组重复的方法调用，同时具有较少的冗余字符和更短的行。缺点是使用了一个非常短且语义不清的标识符“d”。在

什么是最可读的解决方案？如果“缩写变量”是从本地范围内的未经缩写的版本显式赋值的，它的使用是否可以接受？在

Answer 1

我会同意实施方案2，但这是一个非常关键的问题。在

我认为#2和#3同样可读。想象一下如果你有100个映射。。。不管怎样，如果不滚动到顶部，我无法判断底部的代码在做什么。在#2中，为数据命名；在#3中，为函数命名。基本上就是洗衣服。在

更改数据也是一种洗礼，因为无论哪种方式，您只需在与已有数据相同的模式中添加一行。在

如果您想更改对数据所做的操作，就会出现差异。例如，假设您决定为定义的每个映射添加调试消息。使用#2，向循环中添加一个语句，它仍然很容易阅读。使用#3，您必须创建lambda或其他东西。lambdas没有什么问题——我和其他人一样喜欢Lisp——但我想我还是会发现#2更容易阅读和修改。在

但这是一个关键时刻，你的品味可能会有所不同。在

Answer 2

又来救人了！尝试使用星图-下面是一个简单的演示：

list(itertools.starmap(min,[(1,2),(2,2),(3,2)]))

印刷品

^{pr2}$

starmap是一个生成器，因此要实际调用这些方法，必须使用一个列表来使用生成器。在

import itertools

def define_many_mappings_4(self):    
    list(itertools.starmap(
        self.define_parameter_mapping,
        [
            ("status", "current_status"),
            ("id", "unique_id"),
            ("location", "coordinates"),
        ] ))

通常，我不喜欢使用伪列表结构来调用函数序列，但这种安排似乎解决了您的大多数问题。在

如果define_parameter_mapping返回None，那么可以将list替换为any，然后所有的函数调用都将被执行，并且您不必构造那个伪列表。在

Answer 3

我认为#3并不坏，尽管我可能会选择一个比d稍长的标识符，但通常这种类型的东西会变成数据驱动的，因此，您会发现自己使用的是#2的变体，在这里，您将在数据库查询或配置文件中的某个结果上循环