I'm coding in a non-functional language with functional mechanisms (C# to be specific, but you could substitute, say C++ and use function pointers, or what have you) on a small team. It's my habit to use functional techniques -- passing delegates (objects representing functions) as arguments, using closures, occasional anonymous functions, etc -- and I try to document this better than I think a reasonable programmer would need them documented. Looking at code I see online and on Stack Exchange communities, I think my style is pretty normal among C# developers.

Our team, however, isn't sophisticated in these techniques and I end up having to explain (and defend) myself -- my high level of documentation is actually used as evidence by them that I shouldn't code the way I do for the sake of readability.

Now, given the make-up of my team, I understand that I might just give up the good fight here and code to their standards, understanding its better for the team. Does anyone have successful experience using empirical studies, accreditation criteria or best practices lists published by respectable sources that suggest that programmers today have more experience in these functional programming idioms, and that, therefore, we don't need to shy away from them for purposes of maintainability?

  • 4
    You should never document "what" your code do anyway. Document "why" only.
    – SK-logic
    Aug 21, 2013 at 21:13
  • Touche. I have been dutifully rebuked.
    – jwrush
    Aug 21, 2013 at 21:19
  • 2
    Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
    – gnat
    Aug 21, 2013 at 21:44
  • 1
    Note that the question isn't about what concepts they are "supposed" to know, but rather what concepts they can be "expected" to know -- IE, what can I use without having to worry that a reasonable programmer will understand what I was doing. And I think that's a fair question. (Just as there are concepts of procedural or logical programming one can assume any programmer will know.) The people who do maintenance on my code will not always be the team I currently have: I must, in some sense, write towards an imaginary audience.
    – jwrush
    Aug 21, 2013 at 23:48
  • 1
    "are there any empirical studies, accreditation criteria or best practices lists published..." - this site is not tour being a proxy for a search engine
    – gnat
    Aug 23, 2013 at 17:29

2 Answers 2


I would expect any professional C# or web developer in 2013 to be familiar with anonymous functions, closure basics, and the concept of passing methods around. .NET 3.5 has been out for years now, and should be pervasive.

I would expect most professional developers (of any sort) to understand other tangential concepts to functional programming like immutability and pure functions, and how these apply to program design. These concepts too have been around in mainstream programming for ages (and more prevalently in the past 5 or so).

That said, I would not be surprised if more than half of applicable professional developers were completely oblivious to these concepts - and you are largely correct that you should conform to what is best for the team, just like they're largely correct that high levels of documentation is a smell towards unreadable code.

So conform for now and work at training people up, likely through some combination of explicit training and gradual use of more complicated functional structures (where appropriate).

  • I do honestly think in this case that my excessive documentation isn't because the code itself is unreadable, but because I've lost trust. Under other circumstances I would think these areas would need little to no explanation. But this is a very good answer.
    – jwrush
    Aug 21, 2013 at 21:22

In C#, functional programming is a proper tool when you have to navigate through collections. In those cases, functional programming makes the code much shorter and helps focusing on the problem instead of its implementation, while reducing the risk of making mistakes.

You can hardly be accountable of reducing the codebase and the margin for errors by using a proper tool.

The issue you have with your colleagues, I have it in the company I'm currently working in. Most programmers there don't know very well neither C#, nor programming in general, which makes me a not so popular person, given that my colleagues have a hard time understanding the code which uses parallel programming, functional paradigms, code contracts and other features of .NET Framework.

One of the rules each developer should follow is that their code should be understandable in a given context. This conflicts with the fact that one shouldn't be forced to reduce code quality just because he works with unskilled people.

There are two solutions:

  1. Teach your colleagues functional programming and other things you know and they don't, trying to increase their level at yours. This is what I've chosen in my case and what I would suggest to anyone.

    Pros: the quality of the codebase will only increase, and you may appreciate better to work with more skilled colleagues.

    Cons: many programmers don't want to learn things. They work for money, and they don't care about their work. Trying to teach them anything would be an extremely difficult task and one should be ready to receive heavy resistance.

  2. Start writing crappy code written for beginners. Given that this may be disastrous for the motivation, this solution should be taken only when working with people who are unable and/or unwilling to learn and in a circumstance when you can quit soon.

    Pros: this can enhance relations with coworkers if they don't want to learn things and don't want to make effort reading your code.

    Cons: this will decrease the quality of the codebase. Working on badly done projects which would inevitably fail is not very motivating.

Finally, should programmers know functional programming? It depends. It would be mandatory for any person who works daily with C# to know what are anonymous types and lambda expressions and how to use them in C#; on the other hand, I wouldn't say that the same person who don't know what a monad is should be treated as an incompetent.

The difference is that anonymous types and lambda expressions are the inherent part of C# nowadays, while the term monad doesn't exist in C# world.

On the other hand, I'm expecting a developer to be familiar to functional programming concepts like monads, even if this developer never used them. This is because developers are expected not only to write code in a given language, but have enough general culture and curiosity beyond the tools they use daily.

  • Any suggestion as to how I can convince them that they just don't know C#, when they think lambda functions are black magic?
    – jwrush
    Aug 21, 2013 at 21:34
  • 2
    @jwrush: don't convince them they don't know C#: they can take it negatively. Instead, have a more diplomatic approach: ask them if they want to learn a hint about the way to optimize their code, then talk about things they don't know, but in a manner of a friendly discussion, not a lecture. Aug 21, 2013 at 21:58
  • @jwrush maybe warn them that there are few and getting fewer opportunities for .NET 2.0 developers (which is basically what they are) and that for the sake of their careers it would be smart to move into this decade sometime soon? Aug 21, 2013 at 22:26
  • 1
    @Carson63000: I do not think that one should learn a programming language feature for the sake of being "modern", but rather because they think that it provides a better solution. Saying that certain features have been in C# for a while is not a convincing argument.
    – Giorgio
    Aug 21, 2013 at 22:30
  • @Giorgio: I didn't say they should learn these features for the sake of being "modern". I said they should learn these features for the sake of not shacking their career to technology that is seeing rapidly diminishing demand - and this (three major versions behind current release) subset of C# is. As an aside, I'd largely agree with your premise if we were talking about something genuinely new - but .NET 3.5 released nearly six years ago, and in my experience 3.5+ has been almost universally adopted because it does provide a better solution. Aug 21, 2013 at 23:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.