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.)

  • 7
    Arguments against duplicate code (assuming boilerplate is copy/pasted): stackoverflow.com/a/2490897/1583
    – Oded
    May 14 '12 at 18:54
  • 1
    @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. 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
  • 2
    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

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++.

  • 7
    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.
    – user7043
    May 14 '12 at 19:19
  • 6
    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
  • 1
    @Giorgio: On the contrary, it's much more than just my opinion; it's the opinion of the vast majority of people who have ever tried to study it. And when "difficult to read" is inherently a matter of opinion in the first place, the fact that that opinion is so widely shared pretty much makes it a fact. Dec 5 '14 at 1:04
  • 1
    @Mason Wheeler: How people perceive programming languages is often influenced by their past experience. People who learned to program in Scheme find C or Pascal clumsy and difficult to read. On the other hand, the vast majority of people learned to program in a mainstream language.
    – Giorgio
    Dec 5 '14 at 6:56
  • 2
    I'm of the opinion where when more context is hidden from the programmer by removing boilerplate that only means that the Human has to keep a bigger mental map of all the stuff happening unseen behind the scenes And that is a bigger detriment when it comes to debugging than saving a little visual space when authoring. Mar 1 '19 at 0:06

The evolution of efficiency

You start with this:

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

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 )


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.

Update: i've just come across an article giving my example above an actual name: "too DRY anti-pattern".

The function gets more parameters and has increasingly complex internal logic to control its behavior in different cases. Too DRY functions are easy to spot. They have lots of intricate if-then logic that try to address a wide diversity of usage. [...] Also, repeating code isn’t always a bad thing if the code is small and performs a discrete function.

It's a short and interesting read, you can find the article here: Too Dry Anti-Pattern

  • 1
    "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. May 15 '12 at 17:43
  • 4
    +1. Don't repeat yourself, but don't go to awkward lengths to avoid almost repeating yourself. Dec 4 '14 at 16:12

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)

    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)

    if (shouldIDoodle)

    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.

  • 2
    I preferred the second part of your answer. ;p +1 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 :) May 15 '12 at 18:45
  • Idk, wouldn't it be easier and cleaner to avoid code duplication without making things more complicated by passing grommit and doodle functions as arguments to the original function extended by second, or better variadic, function argument?. In other words, adding bool switches and conditionals is just a bad pattern. The example does replacing a bad pattern (code duplication) with one that's worse. If you cannot pass functions, that would have been a point where refactoring in two distinct functions would have been an option, without previous code duplication.
    – gschenk
    Feb 19 '20 at 17:13

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.

  • However, I'm still quite happy with the result I have at the moment, and gladly use it in my spare time projects. :) 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 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. :) May 14 '12 at 19:59

I'm going to take a different tact. Consistency in development is one of the most important features of software design, it's a critical tool in making applications extensible and maintainable but can be difficult to achieve when managing a team across multiple sites, languages and timezones.

If achieved, consistency makes code much more accessible "once you've seen one, you've seen them all", much cheaper to maintain and refactor, but above all, much easier to extend. When you write a library that does require some boilerplate, along with the power of your library you've also given the developer:

  • A starting point understand the preamble (boilerplate) into your functionality, most key classes and access points will usually feature as part of the boilerplate. This gives developers a starting point into the documentation
  • Expectations your placing on developers will become apparent, for example if you setup a tracing object as part of the preamble then developers will know where to log exceptions and information
  • Implicit understanding as you force the developer to go through your process of instantiating classes, they can infer the techniques they will need to access the rest of your library and have the opportunity to introduce them to any conventions you've used throughout your library
  • Easy validation when your boilerplate code is needed it can usually very easily validate itself with exceptions and guard clauses, preventing consumers from getting stuck much further down the line when you're already committed to a faulty process
  • Configuration of a library that requires boilerplate code is easy as there is already an obvious implementation point to customise the functionality for a single path of execution. This is particularly useful if your required boilerplate code is enhanced with the Factory or Command pattern

When the consumers of your library have a grip on the instantiation they can easily create private/extension methods, parent classes or even templates to implement the boilerplate code.

  • Nicely stated. I especially agree with your Expectations and Implicit understanding sections.
    – SMBiggs
    Apr 14 '20 at 6:47

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.

  • 2
    How is this an argument in favour of boilerplate? Oct 15 '12 at 17:01

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.

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