整合编码风格：Funcs、私有方法、单一方法类
我们目前有 3 名开发人员，其中一些风格相互冲突，我正在寻找一种为王国带来和平的方法...
程序员：
Foo 1 ：喜欢使用Func的&操作位于公共方法内部。他使用操作来别名化冗长的方法调用和 Func，以执行可以用 1 或 2 行表达的简单任务，并且将在整个代码中频繁使用
优点：他的代码主体很简洁并且非常可读，通常每个类只有一两个公共方法，很少有私有方法。
缺点：方法的开头包含其他开发人员不喜欢阅读的 lambda 丰富代码块；有时，可能包含其他开发人员真的不喜欢阅读的高阶函数。
Foo 2：喜欢为公共方法必须做的（几乎）所有事情创建一个私有方法。
优点：公共方法仍然很小且可读（对所有开发人员而言）。
缺点：私有方法有很多。使用调用其他私有方法的私有方法，调用...等等，使代码难以导航。
Foo 3：喜欢为每个需要执行的重要任务创建一个具有单一公共方法的公共类，然后将它们依赖注入到其他对象中。
优点：易于测试、易于理解（一个对象，一种责任）。
缺点：项目中充斥着类，打开多个类文件来了解代码的作用会使导航变得很困难。
如果能够充分利用所有这些技术，那就太棒了...
Foo-1 拥有非常好的、可读的（几乎类似 dsl 的）代码...在大多数情况下，除了所有 Action 和 Func lambda 恶作剧都聚集在一起方法的开始。
Foo-3 具有高度可测试和可扩展的代码，对于某些解决方案来说感觉有点“腰带和大括号”，并且有一些代码导航问题（不断地在 VS 中按 F12 并打开 5 个其他 .cs 文件来了解什么是单一方法即可）。
还有 Foo-2...好吧，我不确定我是否喜欢这个包含 2 个公共方法和 12 个私有方法的庞大 .cs 文件，除了它更容易让初学者深入研究这一事实。
我承认我对这些编码风格的解释过于简单化了；但如果有人知道任何可以帮助我们的三个开发人员团结起来的模式、做法或外交策略（而不只是告诉他们中的任何一个人“停止它！”），那就太好了。
从可行性的角度来看：
- Foo-1 的风格遇到了最大的阻力，因为一些开发人员发现 lambda 和/或 Func 难以阅读。
- Foo-2 的风格遇到的阻力较小，因为它很容易陷入其中。
- Foo-3 的风格需要最具前瞻性的思维，并且在时间紧迫的情况下很难执行。
关于一些可以使其工作的编码风格或约定有什么想法吗？
We currently have 3 devs with, some, conflicting styles and I'm looking for a way to bring peace to the kingdom...
The Coders:
Foo 1: Likes to use Func's & Action's inside public methods. He uses actions to alias off lengthy method calls and Func's to perform simple tasks that can be expressed in 1 or 2 lines and will be used frequently through out the code
Pros: The main body of his code is succinct and very readable, often with only one or 2 public methods per class and rarely any private methods.
Cons: The start of methods contain blocks of lambda rich code that other developers don't enjoy reading; and, on occasion, can contain higher order functions that other dev's REALLY don't like reading.
Foo 2: Likes to create a private method for (almost) everything the public method will have to do .
Pros: Public methods remain small and readable (to all developers).
Cons: Private methods are numerous. With private methods that call into other private methods, that call into... etc, etc. Making code hard to navigate.
Foo 3: Likes to create a public class with a, single, public method for every, non-trivial, task that needs performing, then dependency inject them into other objects.
Pros: Easily testable, easy to understand (one object, one responsibility).
Cons: project gets littered by classes, opening multiple class files to understand what code does makes navigation awkward.
It would be great to take the best of all these techniques...
Foo-1 Has really nice, readable (almost dsl-like) code... for the most part, except for all the Action and Func lambda shenanigans bulked together at the start of a method.
Foo-3 Has highly testable and extensible code that just feels a bit "belt-&-braces" for some solutions and has some code-navigation niggles (constantly hitting F12 in VS and opening 5 other .cs files to find out what a single method does).
And Foo-2... Well I'm not sure I like anything about the one-huge .cs file with 2 public methods and 12 private ones, except for the fact it's easier for juniors to dig into.
I admit I grossly over-simplified the explanations of those coding styles; but if any one knows of any patterns, practices or diplomatic-manoeuvres that can help unite our three developers (without just telling any of them to just "stop it!") that would be great.
From a feasibility standpoint :
- Foo-1's style meets with the most resistance due to some developers finding lambda and/or Func's hard to read.
- Foo-2's style meets with a less resistance as it's just so easy to fall into.
- Foo-3's style requires the most forward thinking and is difficult to enforce when time is short.
Any ideas on some coding styles or conventions that can make this work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根本不清楚为什么您不喜欢 Foo-2 的私有方法。
您抱怨“巨大”的 .cs 文件 - 但为什么它会比 Foo-1 的样式大得多？代码量是相同的，只是操作被分成方法而不是表达为 lambda。
老实说，Foo-2 对我来说似乎是最好的选择。将您的公共 API 保留为您想要公开的 API，然后以最简单的方式实现它。虽然 lambda 在某些情况下绝对合适，但 Foo-1 的风格听起来像是将其发挥到了极致 - 超出了真正合理的范围。
特别是，请考虑您的两个公共方法是否有一些共同的子任务。 Foo-1 的方法最终会复制该代码 - Foo-2 的方法会将公共代码放入从两者调用的私有方法中......这对我来说似乎是一个明智的方法。
同样，您谈论私有方法调用私有方法......当然，等效的 Foo-1 代码将是 lambda 表达式调用 lambda 表达式，这几乎没有什么更好！
此外，如果您对白盒单元测试感到满意，Foo-2 的方法可以通过单独测试实现的“较小”部分来更轻松地测试“大块”公共 API 实现 - 诚然，这迫使您使用内部可见性私有的方法，或使用反射。
Foo-3 听起来完全是一种不同的方法，因为它改变的是公共 API 而不是实现。这更多的是设计而不是编码风格，应该单独考虑。
It's not at all clear why you dislike the private methods for Foo-2.
You complain about a "huge" .cs file - but why would it be significantly larger than Foo-1's style? The same amount of code is there, it's just that the actions are split into methods rather than expressed as lambdas.
Foo-2 seems the best option to me, to be honest. Keep your public API to only what you want to expose it, and then implement it in the simplest way. While lambdas are definitely appropriate in some situations, Foo-1's style sounds like it takes it to the extreme - beyond where it's really sensible.
In particular, consider if your two public methods have some common subtask. Foo-1's approach would end up duplicating that code - Foo-2's approach would put the common code in a private method called from both... which seems like a sensible approach to me.
Likewise, you talk about private methods calling private methods... surely the equivalent Foo-1 code would be lambda expressions calling lambda expressions, which is hardly any better!
Additionally, if you're happy with white-box unit testing, Foo-2's approach can make it easier to test "chunky" public API implementations by testing the "smaller" bits of the implementation individually - admittedly forcing you to use internal visibility instead of private for the methods, or using reflection.
Foo-3 sounds like a different approach entirely, in that it's changing the public API rather than the implementation. That's more about design than coding style, and should be considered separately.
我想说，在引入新的规则和约定之前，您应该留出一些团队时间，并在开发团队中就当前的代码库发起尊重和开放的讨论。让您的开发人员讨论编码风格以及他们对代码库及其编码风格混合喜欢和不喜欢的事情。
简而言之，把事情公开化；这比让感情恶化更健康，即使你引入新规则来解决代码问题，政治也可能会继续存在。
让团队感觉他们被视为明智的成年人，并且他们对您引入的编码约定有一些投入和影响。
首先尝试自我监管方法总是值得的，如果讨论进展顺利，您可能不需要强制执行任何操作。
最重要的是：尽量确保每个人都在倾听（包括你自己）。
I'd say that before you introduce new rules and conventions, that you should set aside some team time and initiate a respectful and open discussion within your development team about the current codebase. Get your developers to discuss coding styles and the things that they both like and dislike about the codebase and its mixture of coding styles.
In short, get things out in the open; this is more healthy than letting feelings fester, and even if you introduce new rules to fix the code issues, the politics will likely remain.
Let the team feel that they are being treated as sensible adults and that they have some input and influence upon the coding conventions that you introduce.
It's always worth trying a self-policing approach first, and you may not need to enforce anything, if the discussion goes well.
Most important of all: Try to ensure that everyone listens (including yourself).
对于我的 2 美分来说，它们都有自己的位置，但不应该单独使用任何一种样式，尤其是 1 和 3。样式 1 的代码难以理解，样式 3 会导致难以计算的对象模型。
聚在一起尝试解决这个问题。做到这一点出人意料地困难，而且通常更多的是为了保持一致性而做出妥协，而不是做“正确”的事情。妥协者是这里的无名英雄。 :)
Foo 1
我必须承认我喜欢偶尔使用 lambda 和 funcs 以“协同例程”风格进行编程。然而，这种情况很少见，只有当替代方案不那么简洁或不能清楚地表达设计意图时才使用。
我真的不认为这种编码风格扫描得像一般编程风格（至少在 C# 中），因为许多其他程序员必须使用编译器来弄清楚发生了什么 - 不好。然而它确实有它的一席之地。
Foo 2
这听起来是一种合理的编码风格。事实上，私有方法之间存在依赖关系，这只是小规模的 DRY 工作（如果执行得很好）。
Foo 3
使用 DI 并不强制要求使用这种风格，即每个类只有一个公共方法。这种风格最糟糕的表现是忘记了在面向对象中我们实际上是在尝试对“事物”进行建模。将一大堆没有可识别对象模型的方法粘合在一起并不好，可发现性很糟糕。不过，创建良好的对象模型很难。
For my 2 cents, they all have their place but no one style should be used exclusively, especially 1 and 3. Style 1 has code that is difficult to understand, and style 3 results in an object model that is difficult to work out.
Get together and try and work it out. This is surprisingly difficult to do and is often more about compromise to get consistency than doing what is 'right'. The compromisers are the unsung heroes here. :)
Foo 1
I must admit I like to use lambda and funcs occasionally to program in a "co-routine" style. However, this is rare and only used when alternatives would not be as neat, or express the design intent as clearly.
I really don't think that this style of coding scans well as a general programming style (at least in C#) as many other programmers have to play compiler to work out what is going on - not good. However it certainly does have its place.
Foo 2
This sounds like a reasonable coding style. The fact that there are dependencies between private methods is just DRY working on the small scale (if it is executed well).
Foo 3
Using DI does not mandate using this style i.e. single public method per class. This style at its worst is symptomatic of forgetting that in OO we are actually trying to model 'things'. Gluing together a huge bunch of methods with no discernible object model is not great, discoverability sucks. Creating good object models is hard though.
方便开发人员遵循严格的指导方针确实非常棘手，特别是当新的语言功能出现时，尤其是 Foo-1 开发人员想要使用 lambda。
看起来 Foo-1 和 Foo-2 在使用更多函数式编程方面有一些相似之处。
在你的团队中，主要的开发语言是C#，它主要是面向对象的，所以你必须尝试引入更多面向对象的方法进行开发，并尝试说服他们使用类/对象来实现可重用的代码。其中一项技术是同行评审也会对您的团队成员有所帮助，并不是每行代码都需要它，但是几个启动会话可能会有所帮助，您应该首先与他们一起管理/开始这些评审，然后让他们去做。
It is really very tricky to convenience developers to follow strict guidelines, especially when a new language features come along, especially Foo-1 developer want to use lambda.
It looks like Foo-1 and Foo-2 have some similarities to use more functional programming.
As in your team, the primary development language is C#, which is mainly object oriented, so you must try to bring more object oriented approach towards development and try to persuade them to use classes / objects for reusable code. One of the technique is peer review would also help among your team members, it is not required for every line of code, but couple of starting sessions may help, and you should manage / start those reviews with them first and then let them do.
我确信您对此会有很多不同的意见，但我的感觉是类的内部实现是隐藏的，并且对于该类的使用者来说确实没有多大区别。因此，Foo1和Foo2基本相同，唯一的区别是Foo3。我也不喜欢到处都有多个物体。如果我必须倾向于 Foo1 或 Foo2，我会更喜欢 Foo2，因为它更容易重构并将代码移动到子类中。
I am sure that you will get alot of differing opinions on this, but my feeling is that the internal implementation of a class is hidden and really doesn't make that much of a difference to the consumer of the class. Therefore, Foo1 and Foo2 are basically the same and the only difference is Foo3. I am also not a fan of having multiple objects all over the place. If I had to lean towards Foo1 or Foo2, I would favour Foo2 because it would be easier to refactor and move code into subclasses.