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?
These include: design patterns, abstraction, encapsulation, modularity, polymorphism, and inheritance. When not to use OOP: Putting square pegs in round holes: Don't wrap everything in classes when they don't need to be. Sometimes there is no need and the extra overhead just makes your code slower and more complex.
The object-oriented programming languages are faster and more effective. Procedural uses procedures, modules, procedure calls. Object-oriented uses objects, classes, messages. It focuses on procedure rather data which has priority in data-driven systems.
Benefits of OOP OOP language allows to break the program into the bit-sized problems that can be solved easily (one object at a time). The new technology promises greater programmer productivity, better quality of software and lesser maintenance cost. OOP systems can be easily upgraded from small to large systems.
As a beginner, OOP is also more difficult to read for several non-code related reasons. First, it's near impossible to understand why a piece of code exists if you're unfamiliar with the domain being modeled with classes. Secondly, OOP is a craft and is inherently opinionated.
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!
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With