Consolidation of coding styles: Funcs, private method, single methods classes

Question

We currently have 3 developers with some, conflicting styles, and I'm looking for a way to bring peace to the kingdom ...

Encoders:

Foo 1 : I like to use Func and Action inside public methods. It uses actions to alias long method calls and Func to perform simple tasks that can be expressed in 1 or 2 lines and will be used often through code

Pros: The bulk of its code is concise and very readable, often with one or two public methods for each class and rarely any private methods.

Cons:. The beginning of the methods contains blocks with lambda code that other developers do not like to read; and, sometimes, it may contain higher-order functions that other dev REALLY dislike reading.

---

Foo 2: I like creating a private method of (almost) everything a public method should do.

Pros . Public methods remain small and readable (for all developers).

Against . There are many private methods. With private methods that call other private methods that call ... etc. Etc. It is very difficult to move the code.

---

Foo 3: You like to create a public class with one, public method for each non-trivial task that needs to be performed and then injected into other objects.

Advantages : easily verifiable, understandable (one object, one responsibility).

Cons : the project becomes inundated with classes, opening several class files to understand what the code does, makes navigation inconvenient.

---

It would be great to use all of these methods ...

Foo-1 Has really nice, readable (almost dsl-like) code ... for the most part, with the exception of all the Action and Func lambda synonyms combined together at the beginning of the method.

Foo-3 Has a highly verifiable and extensible code that just perceives a little “belt and loopholes” for some solutions and has some code-navigation errors (constantly hitting F12 in VS and opening 5 other .cs files to find what one method does) .

And Foo-2 ... Well, I'm not sure I like something about one huge .cs file with 2 public methods and 12 private ones, except for juniors it is easier to dig.

I admit that I have oversimplified the explanations of these coding styles; but if anyone knows any patterns, practices, or diplomatic maneuvers that can help bring our three developers together (just without telling any of them just “stop it!”), that would be great.

In terms of feasibility:

• The Foo-1 style meets the most resistance due to the fact that some developers find lambda and / or Func difficult to read.
• The Foo-2 style meets with less resistance, as it just flows so easily.
• Style Foo-3 requires the most advanced thinking and it is difficult to ensure when the time is short.

Any ideas on some coding styles or conventions that might make this work?

Answer 1

I would say that before you introduce new rules and conventions, you should postpone some team time and initiate a respectful and open discussion in your development team of the current code base. Ask developers to discuss coding styles and what they like and dislike about the codebase and its mix of coding styles.

In short, sort out the discovery; this is healthier than letting the senses subside, and even if you introduce new rules to fix code problems, the policy is likely to remain.

Let the team feel that they are treated as rational adults, and that they have a certain contribution and influence the coding rules you have adopted.

First, you should always try the self-defense approach, and you may not need to force anything if the discussion is going well.

Most important: try to have everyone listen (including yourself).

Answer 2

It’s not entirely clear why you don’t like private methods for Foo-2.

You complain about the "huge" .cs file - but why will it be much larger than the Foo-1 style? There is the same amount of code, just that the actions are divided into methods, not expressed as lambdas.

Foo-2 is probably the best option for me. Keep your public API only in that you want to expose it, and then execute it in the simplest way. While lambdas are definitely suitable in some situations, the Foo-1 style sounds like it goes to extremes - beyond where it really makes sense.

In particular, consider whether your two publicly available methods have some kind of common subtask. The Foo-1 approach ultimately duplicates this code - the Foo-2 approach would put the general code in a private method called from both ... which seems like a reasonable approach to me.

Similarly, you are talking about private methods that call private methods ... of course, the equivalent code of Foo-1 will be lambda expressions that call lambda expressions, which is hardly better!

In addition, if you are happy with testing the white box blocks, the Foo-2 approach will simplify testing the “short” public APIs by testing the “smaller” bits of the implementation separately - admittedly, forcing you to use internal visibility rather than private to methods or use reflection.

Foo-3 is completely similar to another approach, as it modifies the public API, not the implementation. It is more about design than coding style, and should be considered separately.

Answer 3

For my two cents, they all have their place, but no style should be used exclusively, especially 1 and 3. Style 1 has code that is hard to understand, and style 3 leads to an object model that is difficult to work from.

Get together and try to figure it out. This is surprisingly difficult to do, and most often it is a compromise to achieve coherence than to do what is “right.” Compromisers are unsung heroes. :)

Foo 1

I have to admit that I like to use lambda and funcs to program in a "co-routine" style. However, this is rare and is used only when the alternatives are not so neat or clearly express the intention of the project.

I really do not think that this coding style scans as well as the general programming style (at least in C #), since many other programmers have to play the compiler to understand what is happening - not good. However, this certainly has its place.

Foo 2

It sounds like a reasonable coding style. The fact that there are dependencies between particular methods, simply a DRMS ​​works on a small scale (if it performs well).

Foo 3

Using DI does not allow using this style, i.e. one public method for each class. At worst, this style is a symptom of forgetting that in OO we are actually trying to model “things”. Bonding a huge heap of methods without a visible object model is small, repulsion settles. However, creating good object models is difficult.

Answer 4

It is actually very difficult for developers to follow strict rules, especially when new language features appear, especially the developer of Foo-1 wants to use lambda.

It seems that Foo-1 and Foo-2 have some similarities to use more functional programming.

As with your team, the main development language is C #, which is mainly object oriented, so you should try to get a more object-oriented approach to development and try to convince them to use classes / objects for reusable code. One method is peer review, which will also help your team members, it is not required for each line of code, but several start-up sessions can help, and you must first start these reviews and then let them do it.

Answer 5

I am sure that you will get a lot of different opinions about this, but I feel that the internal implementation of the class is hidden and does not really affect the consumer of this class so much. Consequently, Foo1 and Foo2 are basically the same, and the only difference is Foo3. I am also not a fan of having multiple objects throughout. If I had to lean towards Foo1 or Foo2, I would prefer Foo2, because it would be easier to reorganize and move the code into subclasses.