我更喜欢

Attributes.Add(string name, string value);

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

这是表达式树的好处之一——可以检查代码本身以获得额外的信息。这就是如何将.Where(e => e. name == "Jamie")转换为等效的SQL Where子句。这是表达式树的一种巧妙使用，尽管我希望它不会超出这个范围。任何更复杂的代码都可能比它希望取代的代码更难，因此我怀疑它将是自我限制的。

我属于“语法卓越”阵营，如果他们清楚地记录它，它看起来非常酷，在我看来几乎没有问题!

欢迎来到Rails Land:)

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

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

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

它的互操作性很差。例如，考虑这个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语言之间有良好的互操作。

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

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

Cons

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

Pros

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

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

不，这当然不是常见的做法。这是违反直觉的，没有办法只看代码来弄清楚它是做什么的。你必须知道它是如何被使用的才能理解它是如何被使用的。

而不是使用委托数组提供属性，链接方法将更清晰，性能更好:

.Attribute("style", "width:100%;").Attribute("class", "test")

虽然输入起来有点费劲，但它清晰直观。

如果方法(func)名称选择得当，那么这是避免维护头痛的好方法(例如:添加一个新的func，但忘记将其添加到函数参数映射列表中)。当然，你需要对它进行大量的文档记录，你最好从该类函数的文档中自动生成参数的文档……

在我看来，这是对羔羊的滥用。

至于语法辉煌，我发现style=>"width:100%"平原混乱。特别是因为=>而不是=

该代码非常聪明，但它可能会导致比它解决的问题更多的问题。

正如您所指出的，现在在参数名称(样式)和HTML属性之间存在模糊的依赖关系。没有编译时检查。如果参数名称输入错误，页面可能不会有运行时错误消息，但很难找到逻辑错误(没有错误，但行为不正确)。

更好的解决方案是拥有一个可以在编译时检查的数据成员。所以不要这样:

.Attributes(style => "width:100%");

带有Style属性的代码可以被编译器检查:

.Attributes.Style = "width:100%";

甚至:

.Attributes.Style.Width.Percent = 100;

对于代码的作者来说，这是更多的工作，但是这种方法利用了c#强大的类型检查能力，这有助于在第一时间防止错误进入代码。

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

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

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

的确，它看起来像Ruby =)，至少对我来说，使用静态资源进行以后的动态“查找”不适合api设计的考虑，希望这个聪明的技巧是可选的api。

当你不需要添加键来设置值时，我们可以继承(或不继承)IDictionary并提供一个像php数组一样的索引器。它将是.net语义的有效使用，而不仅仅是c#，并且仍然需要文档。

希望这能有所帮助

这不仅在一个层面上是可怕的。不，这一点也不像露比。这是对c#和。net的滥用。

关于如何以更直接的方式实现这一点，已经有许多建议:元组、匿名类型、流畅接口等等。

它之所以如此糟糕，是因为它只是为了自己的利益而幻想:

What happens when you need to call this from Visual Basic? .Attributes(Function(style) "width:100%") It's completely counter intuitive, and intellisense will provide little help figuring out how to pass stuff in. It's unnecessarily inefficient. Nobody will have any clue how to maintain it. What is the type of the argument going in to attributes? is it Func<object,string>? How is that intention revealing? What is your intellisense documentation going to say, "Please disregard all values of object"?

我认为你完全有理由感到厌恶。

两个都是。这是对lambda表达式和语法的滥用。

只是想提出我的观点(我是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)。

恕我直言，这是一种很酷的方式。我们都喜欢将类命名为控制器将使其成为MVC中的控制器，对吧?所以在某些情况下，命名确实很重要。

这里的意图也很明确。很容易理解，.Attribute(book= > "something")将导致book="something"， .Attribute(log= > "something")将导致log="something"

我想如果你把它当作一种惯例来对待，那应该不成问题。我的观点是，只要能让你写更少的代码，让你的意图更明显，那就是一件好事。

这是一个有趣的方法。如果你约束右边的表达式为常数，那么你可以实现使用

Expression<Func<object, string>>

我认为这才是你真正想要的，而不是委托(你使用lambda来获得两边的名称) 参见下面的naive实现:

public static IDictionary<string, string> Hash(params Expression<Func<object, string>>[] hash) {
    Dictionary<string, string> values = new Dictionary<string,string>();
    foreach (var func in hash) {
        values[func.Parameters[0].Name] = ((ConstantExpression)func.Body).Value.ToString();
    }
    return values;
}

这甚至可以解决前面提到的跨语言互操作问题。

我能用这个词造个词吗?

Magic lambda (n):仅用于替换魔术字符串的lambda函数。

我认为这不比“魔术弦”好多少。在这方面，我也不太喜欢匿名类型。它需要一种更好的强类型方法。

下面的问题是什么:

html.Attributes["style"] = "width:100%";

All this ranting about "horridness" is a bunch of long-time c# guys overreacting (and I'm a long-time C# programmer and still a very big fan of the language). There's nothing horrible about this syntax. It is merely an attempt to make the syntax look more like what you're trying to express. The less "noise" there is in the syntax for something, the easier the programmer can understand it. Decreasing the noise in one line of code only helps a little, but let that build up across more and more code, and it turns out to be a substantial benefit.

This is an attempt by the author to strive for the same benefits that DSL's give you -- when the code just "looks like" what you're trying to say, you've reached a magical place. You can debate whether this is good for interop, or whether it is enough nicer than anonymous methods to justify some of the "complexity" cost. Fair enough ... so in your project you should make the right choice of whether to use this kind of syntax. But still ... this is a clever attempt by a programmer to do what, at the end of the day, we're all trying to do (whether we realize it or not). And what we're all trying to do, is this: "Tell the computer what we want it to do in language that is as close as possible to how we think about what want it to do."

使软件更易于维护、更准确的关键在于，我们能够更接近于用我们内心认为的方式向计算机表达指令。

编辑:我曾经说过“使软件更具可维护性和准确性的关键”，这是一种疯狂的天真和夸张的独角兽观点。我把它改成了“钥匙”。