我们目前有三个开发者，一些人，有些冲突的风格，我正在寻找一种方法来为王国带来和平......
The Coders：
Foo 1 ：喜欢使用Func＆amp;动作在公共方法中。他使用动作来对冗长的方法调用进行别名，并使用Func来执行简单的任务，这些任务可以用1或2行表示，并且会在代码中频繁使用
优点：他的代码的主体简洁且易读，每个类通常只有一个或两个公共方法，很少有任何私有方法。
缺点：方法的开头包含其他开发人员不喜欢阅读的lambda富代码块;并且，有时，可以包含其他开发人员真的不喜欢阅读的更高阶函数。
Foo 2：喜欢为（几乎）公共方法必须执行的所有操作创建一个私有方法。
优点：公共方法仍然很小且可读（对所有开发人员而言）。
缺点：私有方法很多。使用私有方法调用其他私有方法，调用等等等。使代码难以导航。
Foo 3：喜欢为每个需要执行的非平凡任务创建一个带有单一公共方法的公共类，然后将依赖项注入到其他对象中。
优点：易于测试，易于理解（一个对象，一个责任）。
缺点：项目被类弄乱，打开多个类文件以了解代码导致导航变得尴尬。
最好采取所有这些技术......
Foo-1具有非常好的，可读的（几乎类似于dsl的）代码...在大多数情况下，除了在方法开始时将所有Action和Func lambda shenanigans拼凑在一起。
Foo-3具有高度可测试和可扩展的代码，对于某些解决方案感觉有点“带和 - 带”，并且有一些代码导航的小问题（在VS中经常点击F12并打开其他5个.cs文件来查找一个方法做什么）。
而且Foo-2 ......嗯，我不确定我喜欢任何有关2个公共方法和12个私有方法的巨大.cs文件，除了青少年更容易深入挖掘。
我承认我过分简化了那些编码风格的解释;但是，如果有人知道任何模式，做法或外交手段可以帮助我们三个开发人员联合起来（不要只是告诉他们中的任何人只是“阻止它！”），这将是伟大的。
从可行性的角度来看：
关于某些编码样式或约定的任何想法可以使这个工作吗？
答案 0 :(得分：3)
为什么你不喜欢Foo-2的私人方法，这一点都不清楚。
你抱怨一个“巨大的”.cs文件 - 但为什么它会比Foo-1的风格大得多？存在相同数量的代码，只是将操作拆分为方法而不是表达为lambdas。
说实话，Foo-2对我来说似乎是最好的选择。将您的公共API仅保留为想要公开它的内容，然后以最简单的方式实现它。虽然lambdas在某些情况下绝对是合适的，但是Foo-1的风格听起来就像是把它带到了极致 - 超出它真正明智的地方。特别要考虑你的两个公共方法是否有一些共同的子任务。 Foo-1的方法最终会复制该代码--Foo-2的方法会将公共代码放在一个从两个调用的私有方法中......这对我来说似乎是一种明智的方法。
同样，你谈到调用私有方法的私有方法......当然，等效的Foo-1代码将是lambda表达式调用lambda表达式，这几乎没有更好！
此外，如果您对白盒单元测试感到满意，Foo-2的方法可以通过单独测试实现的“较小”位来更轻松地测试“厚实的”公共API实现 - 无可否认地迫使您使用方法的内部可见性而不是私有，或使用反射。
Foo-3听起来完全是一种不同的方法，因为它改变了公共API而不是实现。这更多是关于设计而不是编码风格，应该单独考虑。
答案 1 :(得分：2)
我要说在您引入新规则和约定之前，您应该留出一些团队时间，并在开发团队中就当前代码库进行尊重和公开讨论。让您的开发人员讨论编码样式以及他们喜欢和不喜欢代码库及其混合编码样式的内容。
简而言之，在公开场合解决问题;这比让感情恶化更健康，即使你引入新的规则来解决代码问题，政治也可能会继续存在。
让团队觉得他们被视为明智的成年人，并且他们对您所介绍的编码惯例有一些投入和影响。
首先尝试自我监管方法总是值得的，如果讨论进展顺利，你可能不需要强制执行任何事情。
最重要的是：尽量确保每个人都倾听（包括你自己）。
答案 2 :(得分：2)
对于我的2美分，他们都有自己的位置，但没有一种风格应该独占使用，尤其是1和3.风格1的代码难以理解，风格3导致难以工作的对象模型进行。
聚在一起尝试解决问题。这是非常难以做到的，往往更多的是妥协以获得一致性而不是做“正确”。妥协者是这里的无名英雄。 ：）
Foo 1
我必须承认，我喜欢偶尔使用lambda和funcs以“共同例程”的方式编程。然而，这种情况很少见，只有当替代品不那么整洁或表达设计意图时才会使用。
我真的不认为这种编码风格很好地扫描为一般的编程风格（至少在C＃中），因为许多其他程序员必须使用编译器来解决发生的事情 - 并不好。但它确实有它的位置。
Foo 2
这听起来像是一种合理的编码风格。私有方法之间存在依赖关系的事实就是DRY在小范围内工作（如果执行得很好）。
Foo 3
使用DI不要求使用这种风格，即每个类的单一公共方法。这种风格最糟糕的是忘记在OO我们实际上试图模仿“事物”的症状。将大量方法粘合在一起并且没有可辨别的对象模型并不是很好，发现性很差。但是，创建好的对象模型 hard 。
答案 3 :(得分：1)
方便开发人员遵循严格的指导方针确实非常棘手，特别是当新的语言功能出现时，尤其是Foo-1开发人员想要使用lambda。
看起来Foo-1和Foo-2与使用更多功能编程有一些相似之处。
与您的团队一样，主要的开发语言是C＃，它主要面向对象，因此您必须尝试将更多面向对象的方法用于开发，并尝试说服他们使用类/对象来获取可重用的代码。其中一项技术是同行评审也可以帮助您的团队成员，每行代码都不需要，但是几个起始会话可能会有所帮助，您应该首先使用它们管理/启动这些评论，然后让它们完成。
答案 4 :(得分：1)
我相信你会对此有很多不同意见，但我的感觉是，类的内部实现是隐藏的，并且实际上并没有对类的消费者产生太大的影响。因此，Foo1和Foo2基本相同，唯一的区别是Foo3。我也不喜欢到处都有多个物品。如果我不得不倾向于Foo1或Foo2，我会赞成Foo2，因为重构和将代码移动到子类会更容易。