Unwillingness to see boilerplate code as a major issue? Why? Countermeasures?

Question

Almost everywhere I worked I met lots of people who didn't care that they produced massive amounts of boilerplate code.

For me this is one of the worst things ever, it leads to errors, it is boring and it increases the noise.

Worst example may be even Microsofts unwillingness to give us a better syntax for this annoying "INotifyPropertyChanged" - stuff. You can't use automatically generated properties, you have to create a big redundancy (replicating the property name in the call to "OnPropertyChanged" or whatever your raiser method is called).

Some people go as far as to accept that most programs in many programming languages consist of mostly the same repeated code (noise), not interesting stuff (signal). See MSDN - examples for example, there is so much unneeded, repeated code all over the place (the horrible "INotifyPropertyChanged" - pattern that ruins all the flow being only the tip of the iceberg).

However, when I raise this issue and propose solutions like AOP (PostSharp.NET) or using delegates (for the non - C# - folks: anonymous functions, often realized using a lambda operator), all I get is "we don't care".

Anyone else here troubled by the insane amount of noise introduced by boilerplate code and who wants to think about ways to push solutions to the boilerplate - issue?

Answer 1

Just kill'em. No, really, if someone writes boilerplate code and doesn't care to improve it, I doubt we may call him professional. It often happens that management wants to see tasks done fast and only thing that's left is to push out some write-only boilerplate code just to make them happy. If your management encourages such approach - change your job.

Answer 2

For what it's worth, I'm completely on your side.

The boilerplate folks argue that the repetitive, redundant code is "automatic" or "consistent" and therefore doesn't contribute to code complexity. Often when a language forces developers to create boilerplate, the industry creates IDEs and other crutches to automate the process. Then, when the apparent cost of producing that boilerplate code approaches zero, people think it doesn't cost anything.

They're wrong: Boilerplate code contributes to code bulk, and anyone maintaining code has to dig through the irrelevant code to get at the important parts. Also, since auto-generated code can and often does get edited, it can hide bugs introduced by typos, incomplete renaming or other accidents. The cost of boilerplate code is not in its creation but in its maintenance - which many projects try to ignore completely.

In the '80s, I saw trade mags plastered with ads for memory leak debuggers for C++, and it was an obvious sign to me that memory management in C++ is seriously broken. Now, in the vicinity of Java and C#, I see a proliferation of code generating assists, and that indicates to me that those languages have issues that would be better solved elsewhere.

Scala has issues of its own, but I love what they've done with properties and auto-initializing constructors.