Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

To me, boilerplate code is obviously bad. However I've met a developer who displays resistance in any attempt to reduce boilerplate. I realized I didn't have a readily formed, well thought out argument past the abhorrence I have developed for it over time.

So that I can form a convincing argument for favoring less boilerplate, what are some counterarguments? In other words what are the arguments (if any) in favor of boilerplate?

(I mean what I think is generally meant by boilerplate, but a good example is getters and setters in Java.)

share|improve this question
6  
Arguments against duplicate code (assuming boilerplate is copy/pasted): stackoverflow.com/a/2490897/1583 –  Oded May 14 '12 at 18:54
    
@Oded: That is right. But you misread the question. :) He is attempting to look if there is anything to say for boilerplate code. My guess is he is very well informed about the disadvantages. –  Steven Jeuris May 14 '12 at 19:06
3  
@StevenJeuris - I read the question perfectly. Which is why I didn't post an answer. I am only adding to the other side of the argument. Just so the OP has "a readily formed, well thought out argument past the abhorrence I have developed for it over time" for next time ;) –  Oded May 14 '12 at 19:06
1  
Boilerplate can be aesthetically pleasing: en.wikipedia.org/wiki/This_Is_the_House_That_Jack_Built –  SK-logic May 15 '12 at 7:21
    
Several good answers and comments that supplement each other... difficult to pick which one to accept. –  abstracted May 16 '12 at 16:34

6 Answers 6

up vote 11 down vote accepted

One important thing to remember is that code is generally made smaller by removing unnecessary context. If the compiler can figure something out, the argument goes, there's no need to write it out explicitly.

And that would be great if only the compiler was ever intended to read it. But remember that "programs should be written for people to read, and only incidentally for machines to execute." (Ironically, this quote comes from a textbook dedicated to one of the hardest of all languages for ordinary human beings to read, due in large part to its excessive terseness.)

What may look like boring, repetitive boilerplate to you as you're writing it can be valuable context to someone else who comes along a year (or five) later and has to maintain your code.

WRT the Java example specifically, I'll agree that that's a good example of bad boilerplate, since it can be replaced by something that's both shorter and easier to read, and also more flexible: Properties. But that doesn't mean that all boilerplate syntactic elements from all languages are as wasteful as the getters and setters from Java and C++.

share|improve this answer
5  
Of course, this argument works both ways. A considerable amount of boilerplate code is just there to appease the compiler and does not help humans comprehend -- to stay with getters/setters, those dozens lines have to be read entirely to be sure "those are just do-nothing getters and setters", rather than reading a single short line per property which simply states that it's a property and what type it has. –  delnan May 14 '12 at 19:19
    
@Delnan: Agreed. That's what I meant by the last line of my answer. –  Mason Wheeler May 14 '12 at 20:50
4  
I think boilerplate is harmful for the human reader as well. By being forced write repetitive, meaningless text, we are obscuring the relevant parts of the code from other people. If something is helpful, then by definition it's not boilerplate. –  Andres F. May 15 '12 at 3:09

The evolution of efficiency

You start with this:

<p>
    <label for="field">My field</label>
    <input type="text" id="field">
</p>

then you get rid of all that annoying boilerplate and put it in a function:

  1. createFieldHtml( id, label )

    this is good, I'm saving myself so many lines!

  2. createFieldHtml( id, label, defaultValue )

    yea, I need a default value too, that was easy to add.

  3. createFieldHtml( id, label, defaultValue, type )

    cool, I can use it for checkboxes now too

  4. createFieldHtml( id, label, defaultValue, type, labelFirst )

    UX designer said label has to be after checkbox.

  5. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate )

    it now renders a date picker when needed. Hm.. params are getting a bit out of hand

  6. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate, containerCssClasses )

    there was this one case where I need to add CSS classes

  7. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate, containerCssClasses, fieldCssClasses, disabled, clearAfter, helpText, uploadPath )

    aaaaaaaaaaaaaaaaaaaaa

In defense of boilerplate

I have a hard time putting this into words because it's really something I've been noticing just recently, so I'll make a list:

  1. It seems to me that there is a certain fear of having duplicate lines that stretch out a bit. If it's just a few lines it might be no problem at all. some things are inherently "almost repetitive" (like the example above). I see little chance in optimizing there in the long run.
  2. People love to encapsulate functionality somewhere; if you look at objectively and it seems like it's just "hiding the mess" -- be suspicious! it might be the time for some good old boilerplate
  3. When you have a function that becomes more and more powerful; that takes many different execution paths depending on the input and ultimately does very little -- it might be boilerplate time!
  4. When you add a layer of abstraction on top of another layer of abstraction, but just to make your code shorter (the underlying layer is not meant to be changed) -- boilerplate time!
  5. When you have a function that takes so many parameters that you really need to have named parameters -- maybe it's boilerplate time.

One thing I recently always ask myself is this:
Can I copy&paste into another project without changing anything? if yes, it's okay to encapsulate or put into a library, if no: it's boilerplate time.

This is very much opposed to the general perception that boilerplate is copy&paste code. To me boilerplate is about copy&pasting, but always having to tweak it a tiny bit.

share|improve this answer
    
"When you add a layer of abstraction on top of another layer of abstraction, but just to make your code shorter" True, you should only add layers of abstraction when there is a possibility of reuse. –  Steven Jeuris May 15 '12 at 17:43

The only real problem with boilerplate code is that when you find a bug in it you have to fix everywhere that you used it rather than the one place that you reused.

share|improve this answer

One argument in favour of boilerplate code is that if you change it in one place, it only affects one flow of the code. This has to be balanced against the fact that more-often-than-not, you actually want a change to affect every piece of code that uses it. But I have seen rare examples that support the argument.

Let's say you have a piece of code that says

public ForTheBar(Foo foo)
{
    Bar bar = foo.bar();
    return bar.BeFooed();
}

This is used in about 2 places in your code.

One day someone comes along and says "ok, in this path only, we want you to Grommit the bar before Fooing it."

And you think "well this is simple."

public ForTheBar(Foo foo, bool shouldIGrommit)
{
    Bar bar = foo.bar();

    if (shouldIGrommit)
    {
        bar.BeGrommitted();
    }

    return bar.BeFooed();
}

Then your user adds some new functionality and you reckon it fits in well with FooTheBar. And you dutifully ask them if you should Grommit that bar before you Foo it and they say "no, not this time".

So you just call the method above.

But then your user says "ok, wait, in the third case, we want you to Doodle the Bar before calling BeFooed."

No problem, you think, I can do that.

public ForTheBar(Foo foo, bool shouldIGrommit, bool shouldIDoodle)
{
    Bar bar = foo.bar();

    if (shouldIGrommit)
    {
        bar.BeGrommitted();
    }

    if (shouldIDoodle)
    {
        bar.BeDoodled();
    }

    return bar.BeFooed();
}

Suddenly your code is becoming less boilerplate. Perhaps you should have accepted the repeated two lines of code. By now you would have three pieces of code, each 2-3 lines long and not looking very repeated any more.

All this said, I would counter that with "this is not a common case, and when it happens, you can refactor."

Another argument I have recently heard is that boilerplate code can sometimes help you navigate code. The example we were discussing was where we'd removed tons of boilerplate mapping code and replaced it with AutoMapper. Now, it was argued, because everything is convention-based, you cannot say "Where is this property set," to the IDE and expect it to know.

I've seen people argue similar things about IoC containers.

Not to say that I agree with them, but it's a fair argument nonetheless.

share|improve this answer
1  
I preferred the second part of your answer. ;p +1 –  Steven Jeuris May 14 '12 at 19:52
    
just realize my example is quite similar to yours... guess even if it's not common sense it appears to happen quite a bit :) –  kritzikratzi May 15 '12 at 18:45

I despise boilerplate code, but being able to remove boilerplate code doesn't always mean that's the best way to go.

The WPF framework has dependency properties, which involves an insane amount of boilerplate code. During my spare time I investigated a solution which greatly reduces the amount of code that needs to be written. Over one year later I am still improving on this solution, and still need to extend on its functionality or fix bugs.

What is the problem? This is great in order to learn new stuff, and explore alternative solutions, but it's probably not the best commercial decision.

The WPF framework is well documented. It properly documents how to write your boilerplate code. Attempting to remove this boilerplate code is a nice exercise, and something which is definitely worth exploring, but achieving the same level of 'polish' as msdn offers takes a long time, which we don't always have.

share|improve this answer
    
However, I'm still quite happy with the result I have at the moment, and gladly use it in my spare time projects. :) –  Steven Jeuris May 14 '12 at 19:37
3  
every time I touch WPF and those dependency properties, I always end up wishing C# had something as simple as C++'s macros. Sure macros are abused in wrong hands, but they could eliminate soooo much repetition here. I'll have to take a look at your AOP framework next time I start wishing for those macros :) –  DXM May 14 '12 at 19:46
    
@DXM If you do, and it crashes miserably, don't forget to blame me and post the errors. ;p –  Steven Jeuris May 14 '12 at 19:48
    
Code snippet worked for me pretty well for dependency properties. –  Codism May 14 '12 at 19:56
    
@Codism: Well, they are a solution, but I despise those too. :) –  Steven Jeuris May 14 '12 at 19:59

The problem with boilerplate is that it violates DRY. In essence, when you write boilerplate, you're repeating the same code (or very similar code) across a number of classes. When that code needs to get changed, it's not at all certain that the developer will remember all of the places that code was repeated. This leads to bugs where old APIs or old methods are used.

If you refactor out the boilerplate into a common library or parent class, then you only need to change code in one place when your API changes. More importantly, when unexpected changes happen, the code breaks in one place, and lets you know exactly what you have to fix in order to get everything working again. This is far preferable to a scenario where one change causes failures in dozens, or even hundreds of classes.

share|improve this answer
    
How is this an argument in favour of boilerplate? –  Chris Wesseling Oct 15 '12 at 17:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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