格式化LINQ查询的最佳方法
在你忽略/投票结束这个问题之前，我认为这是一个有效的问题，因为代码清晰性是讨论的一个重要话题，所以编写可维护的代码是非常重要的，我非常感谢那些曾经遇到过。
我最近遇到了这个问题，因为大量的嵌套，LINQ查询可以非常快速地实现。
下面是我所想到的格式差异的一些例子（对于相同的非复杂的查询）
没有格式化
var allInventory = system.InventorySources.Select(src => new { Inventory = src.Value.GetInventory(product.OriginalProductId, true), Region = src.Value.Region }).GroupBy(i => i.Region, i => i.Inventory); 格式boost
var allInventory = system.InventorySources .Select(src => new { Inventory = src.Value.GetInventory(product.OriginalProductId, true), Region = src.Value.Region }) .GroupBy( i => i.Region, i => i.Inventory);
块格式化
var allInventory = system.InventorySources .Select( src => new { Inventory = src.Value.GetInventory(product.OriginalProductId, true), Region = src.Value.Region }) .GroupBy( i => i.Region, i => i.Inventory );
列表格式
var allInventory = system.InventorySources .Select(src => new { Inventory = src.Value.GetInventory(product.OriginalProductId, true), Region = src.Value.Region }) .GroupBy(i => i.Region, i => i.Inventory);
我想提出一个linq格式的标准，使其最大化的可读性和理解，看起来干净和专业。 到目前为止，我不能决定，所以我把问题提交给这里的专业人士。
我已经解决了块格式。 它困扰了我一段时间的“浪费的空间”的感觉，但最终每个人都觉得它更容易被更多的人阅读。 因为我们已经把新括号放在新的行上，所以它只适合于其余的代码。 解释的空间也较小。 我们在公共商店中保存一个cs文件，格式化示例…当有人想出一个独特的linq我们将其添加到文件…真正帮助新人。
我的格式：
var allInventory = system.InventorySources .Select(src => new { Inventory = src.Value.GetInventory(product.OriginalProductId, true), Region = src.Value.Region }) .GroupBy( i => i.Region, i => i.Inventory );
笔记：
- 在方法上开辟人员永远不值得一个新的路线。
- closures的parens匹配包含开幕paren行的缩进。
- src => new留在与Select相同的行上，因为它不值得换行。
- 匿名types总是得到块处理，就像在查询之外使用一样（但是closuresparen不值得换行）。
- 通常不会调用两个参数GroupBy重载。 虽然它可以很容易地适合在一条线上，但使用额外的一行来清楚说明发生了一些不寻常的事情。
对我来说，这取决于我必须做的查询的长度。 对于简单的简单语句，比如基本select或者简单的连接，我将使用ListFormat格式，因为它使得它不需要将我的代码放在负载线上就可以轻松阅读。
如果我倾向于有一个相当复杂或更大的LINQ语句，我会使用块格式，以便其他人更容易阅读和遵循我正在尝试做的事情。
只要你和自己的方式保持一致，我认为对不同的陈述进行不同的格式化是不好的做法。
它非常主观。
我使用块格式化方法。
我还检查了防止Stylecop的代码，并确保它不会产生任何stylecop警告。
