使用 D 字符串 mixin 进行代码重用是一种反模式吗？

Question

对于那些不熟悉 D 字符串 mixin 的人来说，它们基本上是编译时评估。您可以采用任何编译时字符串（无论是文字还是由模板元编程或编译时函数求值生成）并将其编译为代码。如果您使用简单的字符串文字，它基本上是编译器自动复制粘贴。

您是否认为使用文字的字符串混合作为简单代码重用的一种方式是一种反模式，而其他分解方法不太适合？一方面，它基本上是编译器自动进行的文字复制和粘贴，这意味着一旦混合在实例中，彼此之间就没有任何关系。如果字符串 mixin 中的符号与混合作用域中的符号发生冲突，就会发生不好的事情（尽管是在编译时，而不是运行时）。它相对非结构化，例如，可以将字符串混合到函数中间，当且仅当作用域中的变量根据某种约定命名时，该函数才会起作用。 Mixins 还可以声明外部作用域可以根据需要使用的变量。

另一方面，由于复制粘贴是编译器自动进行的，因此相关代码在源代码级别上有一个事实点，如果需要修改，只需在一个地方进行修改，一切都保持同步。字符串混合还极大地简化了代码的重用，这些代码很难以任何其他方式进行分解，否则很有可能被手动剪切和粘贴。

Answer 1

你提出的所有批评都是真实的。

无论如何，它仍然优于手动复制粘贴。

实际上，我的工具库中正在运行类似的东西，即字符串表扩展。示例代码，来自路径跟踪器的动态值实现：

  T to(T)() {
    static if (!is(T == Scope)) {
      T value;
      if (flatType == FlatType.ScopeValue) value = sr.value().to!(T);
    }
    const string Table = `
                 | bool          | int         | string               | float   | Scope
      -----------+---------------+-------------+----------------------+---------+----------
      Boolean    | b             | b           | b?q{true}p:q{false}p | ø       | ø
      Integer    | i != 0        | i           | Format(i)            | i       | ø
      String     | s == q{true}p | atoi(s)     | s                    | atof(s) | ø
      Float      | ø             | cast(int) f | Format(f)            | f       | ø
      ScopeRef   | !!sr          | ø           | (sr?sr.fqn:q{(null:r)}p) | ø   | sr
      ScopeValue | value         | value       | value                | value   | sr`;
    mixin(ctTableUnrollColMajor(Table,
      `static if (is(T == $COL))
        switch (flatType) {
          $BODY
          default: throw new Exception(Format("Invalid type: ", flatType));
        }
      else `,
      `case FlatType.$ROW:
        static if (q{$CELL}p == "ø")
          throw new Exception(q{Cannot convert $ROW to $COL: }p~to!(string)~q{! }p);
        else return $CELL;
      `
    ).litstring_expand() ~ `static assert(false, "Unsupported type: "~T.stringof); `);
  }

我确信很容易看出没有字符串混合的嵌套 if 和 case 语句是多么可怕、冗余的混乱——这样，所有的丑陋都集中在底部，该函数的实际行为一目了然。

Answer 2

如果可以的话，其他更优雅的解决方案可能会更好，但字符串混合可能非常有用。它们允许代码重用和代码生成。它们在编译时进行检查。生成的代码与您自己手动编写的代码完全相同，因此它的安全性并不比您自己手动编写的代码低。

字符串混合的问题在于，它们比手写代码更难控制，因为它在物理上并没有以相同的方式布置在源代码中，行号可以清楚地追溯到错误，并且可能更难调试。例如，使用字符串 mixin 来表示 hello world：

import std.stdio;

void main()
{
    mixin(hello());
}

string hello()
{
    return "
    writeln(\"hello world\");
";
}

如果我们要删除 writeln() 之后的分号，那么我们得到的错误将是

d.d(7): found 'EOF' when expecting ';' following statement

The mixin is did on line 5. Line 7 is a Blank线。因此，行号在这里的用处有限。现在，这个 mixin 足够短，我们可以将它放在一行上，并让它显示错误与 mixin 在同一行，但对于更复杂的 mixin，这显然不起作用。因此，通过使用字符串混合，您找出错误所在的能力会受到损害。如果代码是使用 CTFE 生成的，那么要弄清楚代码究竟是什么样子从而找出其中的问题就会变得更加困难。这很像弄清楚 C 风格的宏会变成什么代码，只不过情况可能更糟，因为它们可以被生成而不是直接替换。但是，除非您明确告诉它们，否则它们不会进行替换，因此它们比 C 样式宏安全得多。

字符串混合是完全安全的，它们没有什么特别的问题，但它们确实在某些方面使维护变得更加困难。相应的手写代码会更容易调试。然而，字符串 mixin 足够强大，它们可以为您生成大量代码，并从这个意义上为您节省大量维护成本，并且它们允许您重用代码，这也可以是一个巨大的维护收益。

因此，在特定情况下使用字符串混合是否是个好主意取决于具体情况。我不认为它们有什么特别的问题，我当然不会称它们为反模式，但使用它们既有优点也有缺点，因此它们是否是一个好主意取决于你在做什么。在许多情况下，有更优雅、更干净的解决方案会更好。在其他情况下，它们正是医生所吩咐的。

就我个人而言，我认为如果您希望生成代码，节省自己手动编写代码的精力，并且可能更容易为各种情况生成正确的代码并避免创建新代码的风险，那么它们非常棒。像您这样的错误可能是您在使用 mixin 的每个地方自己编写的。它也是直接重用代码的方法之一，而不必担心函数调用的成本或单继承的限制问题或其他任何通过调用函数或继承而使代码重用变得更加困难的问题。您只需将代码复制并粘贴到每个位置，这样如果您更改代码，更改将正确粘贴到任何地方，而不必担心将它们全部跟踪下来，就像您手动复制并复制代码一样。粘贴的。

因此，在适当的地方使用字符串混合，如果不需要，最好不要使用它们，但使用它们并没有什么问题。

Answer 3

字符串 mixin 就像 goto：应该尽可能避免它，并且应该在需要时使用它。