我发现奇数不是因为它的名字，而是因为没有必要;它可以使用匿名类型，并且更加灵活:

.Attributes(new { style = "width:100%", @class="foo", blip=123 });

这是在很多ASP中使用的模式。NET MVC(例如)，并有其他用途(注意，如果名称是一个魔法值，而不是特定于调用者，也要注意Ayende的想法)

只是想提出我的观点(我是MvcContrib网格组件的作者)。

毫无疑问，这绝对是语言滥用。然而，我不会真的认为这是反直觉的-当你看一个属性的调用(style => "width:100%"， @class => "foo") 我认为这是非常明显的(它当然不比匿名类型方法更糟糕)。从智能感知的角度来看，我同意这是相当不透明的。

对于那些感兴趣的人，它在MvcContrib中使用的一些背景信息…

我把它添加到网格作为个人偏好-我不喜欢使用匿名类型作为字典(有一个接受“object”的参数就像一个接受参数Func[]一样不透明)和字典集合初始化器相当冗长(我也不喜欢冗长的流畅接口，例如必须将多个调用链接到一个属性(“style”，“display:none”)。属性("class"， "foo")等)

如果c#对字典字面量有一个不那么冗长的语法，那么我就不会在网格组件中包含这个语法了:)

我还想指出，在MvcContrib中使用这个是完全可选的-这些是扩展方法，包装重载，以字典代替。我认为重要的是，如果你提供了这样的方法，你也应该支持更“正常”的方法，例如与其他语言的互操作。

另外，有人提到了“反射开销”，我只是想指出，这种方法真的没有太多的开销——没有运行时反射或表达式编译(参见http://blog.bittercoder.com/PermaLink,guid,206e64d1-29ae-4362-874b-83f5b103727f.aspx)。

它的互操作性很差。例如，考虑这个c# - f#的例子

C#:

public class Class1
{
    public static void Foo(Func<object, string> f)
    {
        Console.WriteLine(f.Method.GetParameters()[0].Name);
    }
}

F#:

Class1.Foo(fun yadda -> "hello")

结果:

打印“arg”(不是“yadda”)。

因此，库设计者应该避免这些“滥用”，或者至少提供一个“标准”的重载(例如，将字符串名作为一个额外的参数)，如果他们想在。net语言之间有良好的互操作。

欢迎来到Rails Land:)

只要你知道发生了什么，它就没有什么问题。(当这类事情没有很好地记录时，就会出现问题)。

整个Rails框架是建立在约定优于配置的思想之上的。以特定的方式命名事物将您带入他们正在使用的约定，并且您可以免费获得大量功能。遵循命名惯例可以让你更快地到达目的地。整个系统运作得非常出色。

我还在Moq中的方法调用断言中看到过类似的技巧。你传入一个lambda，但是lambda永远不会被执行。它们只是使用表达式来确保方法调用发生了，如果没有发生则抛出异常。

我更喜欢

Attributes.Add(string name, string value);

它更加明确和标准，使用lambdas什么也得不到。

我几乎没有遇到过这种用法。我认为这是“不合适的”:)

这不是一种常用的使用方式，它不符合一般的约定。当然，这种语法也有优点和缺点:

Cons

代码不是直观的(通常的约定是不同的) 它往往是脆弱的(重命名参数将破坏功能)。 测试起来有点困难(伪造API需要在测试中使用反射)。 如果大量使用表达式，它会变慢，因为需要分析参数而不仅仅是值(反射成本)。

Pros

在开发人员调整到这种语法之后，它的可读性更强。

底线——在公共API设计中，我会选择更明确的方式。