I'm new to the functional programming concepts in C#, but I have some experience with higher order functions via Haskell, Scala, Python and Ruby. I'm currently going through an old .NET 2.0 codebase with a LOT of duplication in it. Most of it is simple "copy/paste" with a few variables changed. I'm trying to condense as much of this as possible.

A chunk of code within a routine I'm working on now goes a bit like this, for example:

Where any of the "V"s you see in there is a string variable defined earlier. It's part of a fairly large method. I could write another method called, say, WriteVariables() and pass in the required info and call it three times, but it only ever applies to this section of method. I think this would be a place where writing an anonymous inner function would make sense.

I did it to test it out, and it seems to work fine. Now I have a single delegate that looks something like:

This might be problem with only this example. But why not use normal method?
–
EuphoricAug 10 '12 at 20:16

@Euphoric I guess that's what I'm trying to figure out. I could use one, but the object is already so bloated and huge, and I'd like to keep the scope of the function as local as possible to prevent additional classwide clutter.
–
KChalouxAug 10 '12 at 20:25

C# is OOP language. Not functional language. There should be nothing like "local function scope". If class is bloated, then fix that class. Don't try to bypass the problem.
–
EuphoricAug 10 '12 at 20:29

@Euphoric Fixing the class is what I'm trying to do. Unfortunately, the schedule they have me on doesn't give me time to completely rewrite it right now, and it's not my call to do a complete overhaul :( Just trying to clean up redundancy where I can so that it's more manageable when the bigger overhaul eventually comes a-knocking.
–
KChalouxAug 10 '12 at 21:00

3 Answers
3

However, if most of the other people developing the software have limited advanced programming experience you might want to use a regular function instead of an anonymous one since it will be more obvious what's going on.

When you're the senior developer and the rest of your team is at a significantly lower skill level; making sure they understand how your code works and can easily modify it if needed is an important consideration. Since your team mostly consists of non-programmers this is a larger consideration, since for programming techniques they probably congregate closer to the Use What I Know end of the scale than the Learn New Things Everyday end.

Breaking the repeated logic out and removing the copy/pasting should be simple to explain the benefits of. More advanced techniques like anonymous functions or linq would be a harder sell since they don't give major and obvious functional/maintenance improvements. The hardware engineers I've worked with in the past mostly only learned C in college since it was the language of choice for the micro-controllers in the gadgets they were building. With only a handful of classes their skills were concentrated on practical basic programming only, and not anything advanced.

Something might make a difference. The ultimate intent of the original designers is for me to take over maintenance and development of the project completely (I'm a junior programmer). The others want to move away from it.
–
KChalouxAug 10 '12 at 20:02

@KChaloux if you're taking primary ownership of the code you've got more latitude to update things. Unless you're confident the hardware people won't end up poking around in the code themselves when things don't behave as expected I'd still try to avoid doing anything that blows their minds. And despite your lack of experience (by years of work); you're the de facto senior developer. In terms of formal training most of your colleagues are probably the equivalent of first year CS students even if the school of hard knocks has since cured them of some of the worst bad student habits.
–
Dan NeelyAug 10 '12 at 20:20

My direct supervisor, despite not having a CS degree, has actually been entrenched in the software side of things for the better half of a decade now. So while he may not have a degree in this particular field, he's knowledgeable enough at least. The other guys who write software here less so, but I'm not sure if they'll touch this code much.
–
KChalouxAug 10 '12 at 20:23

The key question is whether to use a "normal" private function or a strictly local function and the answer should stem from the same decision-making you'd use with a private field vs. a local variable: Is this thing useful anywhere but this function? In this case, it would appear not, so your approach seems correct.

There is an issue with using advanced functional techniques in C#, but C# is evolving to have more and more functional features, so you ought not avoid all functional techniques only because they may still be unfamiliar. I would say that this would actually be the type of use that would be good in a codebase where people were relatively unfamiliar with functional programming, since it is very straightforward in both utility and implementation.