Should one avoid certain programming constructs (and others) for maintenance's sake?

Question

I'm working on a non-personal project, so it's safe to say that the maintenance programmer will not be me, for otherwise I wouldn't need to ask this question.

Now there are some constructs (delegates, lambda expressions) which I would like to try in my code, not to intentionally make the code harder to read, but because they lend themselves to the situation (and less code to type as well), and to practice using them as well since I'm new to the language.

However, I'm not sure if the maintenance programmer will know every construct, as many of us didn't come from a c# background, and I'm not sure if he's as enthusiastic about programming as me or just treat it like a regular day job. So my questions are:

• Should certain programming constructs be avoided to improve maintainabilily?

• If the answer to the above question is yes, then is the subset of constructs which one should avoid using?

• Is it the responsibility of the maintenance programmer to learn a language fully?

Answer 1

I'm against Least-Common-Denominator coding. We're professionals, part of what we should be expected to do is learn things that we don't know.

On the other hand, I'm also against glory-coding. Use the simplest constructs that can get the job done - debugging code is twice as hard as writing it, so you'd better only write code half as clever as you're capable of!

Answer 2

I think the general rule of thumb is to make sure your code is readible with lots of comments, especially in places where you are doing anything that is not straight forward.

Avoiding certain constructs like delegates and lambda expressions shouldn't be the way to go, if used correctly and sensibly, language features like those can greatly reduce the complexity of your code and make them more concise and expressive. After all, that's the beauty of LINQ, is it not? ;-)

I think you should focus on getting your part of the job done as best as you can, whether or not the other programmers have all the necessary knowledge to understand your code is out of your control. If that maintenance programmer leaves, and someone else comes in, what then? You shouldn't tailor your code to suit the maintenance programmer, tailor your code to suit the problem you're tasked to solve instead.