I'm not sure exactly, but as far as I can tell, boiler-plate code is repetitive mostly excessive code. Boiler plate code should be abstracted away where-ever practical.

==

Some types can't be avoided through abstraction. As with,

Iterator myIterator=myList.iterator();

while (myIterator.hasNext())
{
  Object next=myIterator.next();
  String stringNext=null;

  if (next instanceof String)
    stringNext=(String)next;
  else
    //Throw error

 //process stringNext

The only good fix was a change of language:

List <String>myList;

...
for (String next : myList)
{
  //process next

''This is one of the many good things about Lisp macros. They let you abstract/hide away most boiler plate...''

----

I am not sure of the legal status of BoilerPlateCode.

Programmers mostly sell themselves as CsharpLanguage programmers or JavaLanguage programmers. Some of these programmers also have experience with other languages, but find that experience less marketable.

CsharpLanguage and JavaLanguage are both verbose languages, where even a simple concept can expand into a dozen or so lines of code.

Every now and then the language the programmer is using at work lacks some feature, but this is OK because the programmer can write it in a few lines of code using features that do exist. (This may be a feature that is present in another language, or it may just be something that was omitted from an API. For example, LINQ provides extension methods to convert any enumerable to a list, array, or dictionary, but hash sets were overlooked. It is trivial to write an extension method that converts an enumerable to a hash set.) (Sometimes, too, a programmer will reach for a .NET 4 feature, but the company is still using .NET 3.5, so the programmer writes a class My''''''Lazy<T> to stand in for Lazy<T>...)

Sometimes there are also commonly needed routines, such as a function which takes a string and returns it with quotes around it and proper escapes inside it. Sometimes these routines are common enough that a programmer might need them more than once, but not so common that they merit a place in the language's standard library.

If a programmer works with the same languages and APIs, and uses them in the same ways, then that programmer will find the same holes in those languages and APIs, and will fill those holes in the same ways.

It is entirely possible that many programmers develop their own personal boilerplate and memorize it. Sometimes it is not necessary to memorize boilerplate, though; sometimes when a certain problem arises, there are a limited number of ways to solve it, so the programmer ends up generating approximately the same code, even without being able to see the previous code. Even without realizing it.

The programmer may write the same boilerplate code for many employers, and possibly also for open source projects (if the open source is in the same language that the programmer uses at work).

The problem is, the law doesn't make any clear distinction between boilerplate code and any other code. Boilerplate is technically copyrighted, and some lawyer could have a field day, claiming basically that the programmer who wrote a piece of boilerplate would have assigned the copyright to the first employer, and then violated copyright with subsequent employers and also with the open-source stuff. The lawyer can speculate about what kinds of royalties the first employer could have charged for this boilerplate, and thus the lawyer can manufacture "damages" to that employer. The lawyer could even make arguments that the boilerplate code is (or was) some kind of trade secret and is (or should have been) subject to inevitable disclosure, etc.

This can also be a problem with those five-line snippets you find on StackOverflow, although in this case the programmer could get into trouble for "copying and pasting code from the Internet."

Interestingly, if two programmers independently come up with the same boilerplate, then they are not infringing on each other. Copyright is not concerned with independent invention.

Copyright law does specify that copyright only covers the "creative expression" in a piece of code. It is arguable that if you have only one or two choices of how to encode something into, say, JavaLanguage, there is no creativity, and therefore, nothing to which the copyright can apply. This description suits boilerplate well, and it is also why no one can copyright the word "the."

In the Oracle vs. Google case, the jury found that twelve lines of code were copied from Oracle's code to Google's code. (This sounds to me like personal boilerplate...) The judge decided that this was trivial, but there is an appeal in progress.