C# coding style, functional approach was closed for being opinion-based.

But consider what was really being asked here. We were presented a development plan and asked if any problems are already apparent.

Answering that requires an experienced eye looking at the plan. It doesn't require an entire book.

For what it's worth here's how I would have answered:

Will it bite me as code base increases?

Things that may bite you:

   public string Name{get;set;}

Public setter indicates shared mutable state. Could be problematic for readability, debugging, or in a concurrent environment. Prefer immutable where possible.

HelperMethods is a poor name for a class or package. I need names that tell me what does and doesn't belong inside. Resist the temptation to leave your pure functions languishing under meaningless names. Good names organize code. As your functions grow in number step back and look at them together and think about better ways to organize them.

A fluent syntax doesn't require static. Neither do pure functions. Static means static. You can choose to use static for this but static isn't giving you purity or fluency. You have to do that yourself.

Consider this example: =

Nutrition secretFormula(Nutrition nutrition) {
    return nutrition
        .Builder(240, 8)

Because this code takes a reference to Nutrition rather than reach out to it statically it doesn't actually know what implementation of Nutrition it's talking to. That means this code doesn't need to be touched if you need to change how Nutrition works. Sure the new version of Nutrition has to be backwards compatible with this code, but it's engine is free to do with this whatever it likes.

Opinion based? No more than a code review. I see a potential problem, I say something about it. And it's not a whole book. Just a response to a development plan. Can we really not handle questions like this?

  • 1
    Please cite me correctly: my comment "there are whole books about this topic" was not referring to the question, but about the sentence directly before that ("But the larger your program will get, the more structure it will require."). My close vote was "too opinionated" (and it stands - for my taste, it is 100% opinionated at which point in time the points you mentioned will really become a problem), But alas, if you really want to write an answer, I will vote to reopen.
    – Doc Brown
    Oct 25, 2022 at 15:58
  • 1
    ... I still don't like the question, because it is not clear which points in the code look too simple because the OP shortened their approach to make it fit into the box, or because the OP really wants to keep things "that simple" even when the program grows.
    – Doc Brown
    Oct 25, 2022 at 16:03
  • I would like to answer but more than that I'd like to get on the same page as you. My approach to answering this in an objective way was to react to issues with the plan that seem to impede growth. Code Review picks over code much the same way. Sure different people may notice different things and point out things not everyone agrees on but it's still narrow enough to pick a best answer based on something more than who posted first. Oct 25, 2022 at 16:30
  • as for the OP wanting to keep things "that simple" I'd expect they'd love to know how to tell when it's time to abandon insisting on keeping it "that simple". Oct 25, 2022 at 16:32


You must log in to answer this question.

Browse other questions tagged .