How to stop functional programming

Re:How to stop functional programming by Jtsummers on Tuesday February 23, 2016 @02:18PM (#11161512)

I have to ask, where do you draw the line? I had a team lead that disliked me writing things like (in C#, been a bit so forgive errors):

  List<AClass> original; // perhaps as a parameter to the function
  List<AClass> filtered = original.Where(x => x.Field > 10);

Arguing that I should instead have just used for loops (showed him foreach and he agreed that that was better, at least) like:

  List<AClass> filtered = new List<AClass>();
  foreach(x in original)
    if(x.Field > 10) filtered.Add(x);

Ok, so it's only two lines longer (three if you split the if and its effect, 5 if you also add in braces, 7 if you put opening braces on their own lines). The `Where` version is not that complicated, and only requires understanding one (potentially) new concept for programmers, namely anonymous functions.

Wouldn't the briefer, but still clear, code be preferable for maintenance?

[ Parent | on HN ]

Re:How to stop functional programming by steven777400 on Tuesday February 23, 2016 @03:17PM (#11161945)

Yes absolutely. I don't say "no functional constructs" nor does anyone else here that I know of. However, composite LINQ statements, especially involving aggregation can and do become confusing. Obviously it's a judgment call but in many cases, breaking out a complex expression into incremental, imperative steps can and does make it clearer.

The "rule" I apply is "code should be written primarily for people to read and only incidentally for machines to execute" which, although very subjective, provides a good foundation for everyone to start from.

[ Parent | on HN ]