What is boilerplate code? - terminology

A coworker had never heard of this, and I couldn't provide a real definition. For me, it's always been an instance of 'I-know-it-when-I-see-it'.
Bonus question, who originated the term?

"boilerplate code" is any seemingly repetitive code that shows up again and again in order to get some result that seems like it ought to be much simpler.
It's a subjective definition.
The term comes from "boilerplate" in the newspaper industry: wiki

Boilerplate code means a piece of code which can be used over and over again. On the other hand, anyone can say that it's a piece of reusable code.
The term actually came from the steel industries.
For a little bit of history, according to Wikipedia:
In the 1890s, boilerplate was actually cast or stamped in metal ready for the printing press and distributed to newspapers around the United States. Until the 1950s, thousands of newspapers received and used this kind of boilerplate from the nation's largest supplier, the Western Newspaper Union. Some companies also sent out press releases as boilerplate so that they had to be printed as written.
Now according to Wikipedia:
In object-oriented programs, classes are often provided with methods for getting and setting instance variables. The definitions of these methods can frequently be regarded as boilerplate. Although the code will vary from one class to another, it is sufficiently stereotypical in structure that it would be better generated automatically than written by hand. For example, in the following Java class representing a pet, almost all the code is boilerplate except for the declarations of Pet, name and owner:
public class Pet {
private PetName name;
private Person owner;
public Pet(PetName name, Person owner) {
this.name = name;
this.owner = owner;
}
public PetName getName() {
return name;
}
public void setName(PetName name) {
this.name = name;
}
public Person getOwner() {
return owner;
}
public void setOwner(Person owner) {
this.owner = owner;
}
}

On the etymology the term boilerplate: from http://www.takeourword.com/Issue009.html...
Interestingly, the term arose from the newspaper business. Columns
and other pieces that were syndicated were sent out to subscribing
newspapers in the form of a mat (i.e. a matrix). Once received,
boiling lead was poured into this mat to create the plate used to
print the piece, hence the name boilerplate. As the article printed
on a boilerplate could not be altered, the term came to be used by
attorneys to refer to the portions of a contract which did not change
through repeated uses in different applications, and finally to
language in general which did not change in any document that was used
repeatedly for different occasions.
What constitutes boilerplate in programming? As may others have pointed out, it
is just a chunk of code that is copied over and over again with little or
no changes made to it in the process.

It's code that can be used by many applications/contexts with little or no change.
Boilerplate is derived from the steel industry in the early 1900s.

From Wikipedia:
In computer programming, boilerplate is the term used to describe sections of code that have to be included in many places with little or no alteration. It is more often used when referring to languages that are considered verbose, i.e. the programmer must write a lot of code to do minimal jobs.
So basically you can consider boilerplate code as a text that is needed by a programming language very often all around the programs you write in that language.
Modern languages are trying to reduce it, but also the older language which has specific type-checkers (for example OCaml has a type-inferrer that allows you to avoid so many declarations that would be boilerplate code in a more verbose language like Java)

Boilerplate is what good programmers avoid: repetition.

Boilerplate in software development can mean different things to different people but generally means the block of code that is used over and over again.
In MEAN stack development, this term refers to code generation through use of template. It's easier than hand coding the entire application from scratch and it gives the code block consistency and fewer bugs as it is clean, tested and proven code and it's open source so it is constantly getting updated or fixed therefore it saves a lot of time as using framework or code generator. For more information about MEAN stack, click here.

Boilerplate definition is becoming more global in many other programming languages nowadays. It comes from OOP and hybrid languages that have become OOP and were before procedual have now the same goal to keep repeating the code you build with a model/template/class/object hence why they adapt this term. You make a template and the only things you do for each instance of a template are the parameters to individualize an object this part is what we call boilerplate. You simply re-use the code you made a template of, just with different parameters.
Synonyms
a blueprint is a boilerplate
a stencil is a boilerplate
a footer is a boilerplate
a design pattern for multiple use is a boilerplate
a signature of a mail is a boilerplate

In practical terms, boilerplate code is the stuff you cut-n-paste all over the place. Often it'll be things like a module header, plus some standard/required declarations (every module must declare a logger, every module must declare variables for its name and revision, etc.) On my current project, we're writing message handlers and they all have the same structure (read a message, validate it, process it) and to eliminate dependencies among the handlers we didn't want to have them all inherit from a base class, so we came up with a boilerplate skeleton. It declared all the routine variables, the standard methods, exception handling framework — all a developer had to do was add the code specific to the message being handled. It would have been quick & easy to use, but then we found out we were getting our message definitions in a spreadsheet (which used a boilerplate format), so we wound up just writing a code generator to emit 90% of the code (including the unit tests).

In a nutshell, boilerplate codes are repetitive codes required to be included in the application with little to no change by the program/framework, and contribute nothing to the logic of the application. When you write pseudo codes you can remove boilerplate codes. The recommendation is to use a proper Editor that generates boilerplate codes.
in HTML, the boilerplate codes in the interface.
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body> </body>
</html>
in C#, The boilerplate codes of properties.
class Price
{
private string _price;
public string Price
{
get {return _price;}
set {_price= value;}
}
}

Joshua Bloch has a talk about API design that covers how bad ones make boilerplate code necessary. (Minute 46 for reference to boilerplate, listening to this today)

You can refer to it as "snippets" or more accurately "collection of snippets" .
The term I think was coined from the press and printing industry, where they used actual "plates" and then re-used them as chunks again..
In modern-day internet it is a part of an ongoing (annoying IMHO) trend of using fancy terms for simple things in order to look more trendy and sophisticated . see RESPONSIVE = adaptable / fluid.

From whatis.techtarget.com :
In information technology, a boilerplate is a unit of writing that can
be reused over and over without change. By extension, the idea is
sometimes applied to reusable programming as in "boilerplate code."
The term derives from steel manufacturing, where boilerplate is steel
rolled into large plates for use in steam boilers. The implication is
either that boilerplate writing has been time-tested and strong as
"steel," or possibly that it has been rolled out into something strong
enough for repeated reuse.
Beyond programming :
A boilerplate can be compared to a certain kind of template, which can
be thought of as a fill-in-the-blanks boilerplate. Some typical
boilerplates include: mission statements, safety warnings, commonly
used installation procedures, copyright statements, and responsibility
disclaimers.
In my experience as a programmer, the proper kind of boilerplate code is typically a bunch of code that you start off with that's not large and/or complicated enough to be called a framework.
A typical example would be the HTML5 Boilerplate.

A boilerplate is a unit of writing that can be reused over and over without change. By extension, the idea is sometimes applied to reusable programming, as in “boilerplate code

Repeatable sections of code which just adds an unnecessary layer of typing to get the job done.
Are these necessary?
For the most part, these are structural and decorative markups. It provides consistency on how a code, function, language could look like.
So its kind of redundant as developers because we have seen it multiple times, but does convey some actual meaning to non-developers and compilers.

Related

If HTML is not a programming language, what am I doing if I am doing HTML codes?

I am creating an article about programming. If I am using C#, for example, I am a C# programmer and I am programming using C#. How about HTML? If HTML is not a programming language, and it is a markup language, what is the correct verb applicable to a person coding in HTML? Is it just coding?
Edit 2:
Wow, apparently you can call HTML/CSS a programming language because HTML5/CCS3 is Turing-Complete by by accident (for first link, check comments).
Main Answer:
"How about HTML?" I take the stance that to be programming, the language has to be Turing Complete. So in my definition you can't be a Regex programmer. The more lean definition is that it needs variables & control statements, as simple as having an 'if' and a 'branch' instruction. So as you point out, pure HTML is not a programming language. But HTML in the real world isn't just html text files!
I would call an HTML user a HTML Techonologist or HTML author but if someone said they were a HTML coder or even a programmer, I wouldn't bat an eye or try to correct them. I don't think many people write plain HTML and the moment one adds Javascript or allows pages to be generated by PHP, python, or anything else it crosses the programming language definition. (edit 2: The moment you add CSS3 it becomes Turing Complete and thus a 'real' programming language)
Edit 1:
I like an answer I found about why 'real programmers' are so defensive over reminding people HTML/CSS is not 'real programming'. The OP's question dealt with what to call HTML authors but this question comes up because 'real programmers' are so firm in making a distinction between their work. I like this quote from Kramli (linked before)
There are times when the difference between programming languages and other languages really does matter. Quite often, however, we can all communicate perfectly effectively when just lump them all in together.
You have three questions...
Q1: I am a C# programmer and I am programming using C#. How about HTML?
A1: I am coding in HTML
Q2: If HTML is not a programming language, and it is a markup
language, what is the correct verb applicable to a person coding in
HTML?
A2: Verb = Coding, But I think you are looking for the term Coder
Q3: Is it just coding?
A3: Yes
HTML is a markup language, hence the name HyperText Markup Language.
You are effectively the modern day equivalent of a typesetter in the print industry.
If you have minimal input in the page creation process then you're probably a Coder, however if you have significant input into page layout, then the job role is normally referred to as being a Web Designer. If you're writing lots of scripts (in say PHP, Python, Ruby, Perl or whatever your least worst option is) to produce the pages in a reasonably professional manner, then you can award yourself the wonderful title of Web Developer :-)
If you devote some thought as to how all these scripts are going to hang together, and how users are going to interact with your site, then you can claim to be an Analyst. :-)
In the Internet, job roles are quite fuzzy; personally I consider myself a mix of all of the above, concentrated more on the Developer/Analyst side as whilst I understand the technical aspects of HTML and CSS, I don't have the appreciation of good design and presentation to fully claim being a Designer in a professional context.
I also suggest you read the answers to the related questions on the right of this page...
As with any language - be it musical, programmatic, mathematical,hyper text or anything in between - as a content creator you are a writer.
Specifically for a mark up language (such as HTML) you are annotating a document with tags that are separate entities from the text between them, and so could be considered an Editor, Author, or Designer because you are generally directing the content of a page.
Differences arise with HTML compared to writing technical documents using, for example, DITA. Where as a DITA document has its architecture and tags, it does not necessarily require a style sheet to be displayed. HTML on the other hand is normally consumed through a web browser so requires CSS transformation to be shown in a readable fashion. For this reason, formatting becomes as important as content and people writing HTML and CSS as a combination are referred to as Web Designers.
If you begin throwing in programming languages such as PHP or JScript you will be referred to as a Web Developer, but developer and designer are often interchangeable between the two options.
what is the correct verb applicable to a person coding in HTML?
coding is a process that involves using programming language. since HTML is not a programming language you can use writing instead of coding. as simple as that.
No, HTML is not a programming language. The "M" stands for "Markup". Generally, a programming language allows you to describe some sort of process of doing something, whereas HTML is a way of adding context and structure to text.
If you're looking to add more alphabet soup to your CV, don't classify them at all. Just put them in a big pile called "Technologies" or whatever you like. Remember, however, that anything you list is fair game for a question.
HTML is so common that I'd expect almost any technology person to already know it (although not stuff like CSS and so on), so you might consider not listing every initialism you've ever come across. I tend to regard CVs listing too many things as suspicious, so I ask more questions to weed out the stuff that shouldn't be listed. :)
However, if your HTML experience includes serious web design stuff including Ajax, JavaScript, and so on, you might talk about those in your "Experience" section.

Is HTML5 a programming language?

Nowadays, we can use HTML5 to make apps, as in android, in firefox os, iPhone, Blackberry and others. But, I heard that HTML is a Markup language, not for programming.
Even with App features, HTML continues to being only a markup language?
Programming languages have certain features, like branching, looping, that sort of thing, that HTML5 lacks. HTML5 defines markup for some interactive features, but the markup is almost entirely static (there's some interaction implied in the definition of select elements and such). A lot of "HTML5" features you hear about aren't HTML5 at all, but rather things you can do with JavaScript (a programming language) in a modestly-capable browser.
HTML5 is increasingly taking over (or has taken over) the role of defining both the structure of web pages and the API to interacting with them from a programming language. That used to be quite separate, in the DOM specs, but a lot of that is now being folded into the HTML5 specification. But again, that's just defining APIs. The actual coding using those APIs requires (in almost all cases) an actual programming language.
Short Answer: No.
Long Answer: No, it isn't. HTML as defined by the standard is just a markup language, exactly as it was in its previous versions.
But what does that mean? It means that it is supposed to structure your data allowing you also to define semantics with the use of markers, but it cannot process or modify your data as you would do using a programming language. Also it has no concept of input or output as is the case in programming languages​​, where you get an input to analyze and produce an output.
By the way HTML5 is coming out alongside a wider interest for the web and also stronger technologies (such as newer versions of javascript and css) which make new web applications even more powerful and limitless.
Please, read this great resource to learn more about HTML5.
HTML5 is considered a technology.
Yes, there is 5th release of HTML markup language but probably you didn't mean that.
HTML5 is more considered to be a technology including HTML,CSS3 and javascript and most of all their support in tools like browsers. So as a matter of fact it can be considered as something that requires programming.
Programming do not means Turing Complete Language. It's a linguistic problem, programing means to plan something, and this Html does very well.
program (n.)
1630s, "public notice," from Late Latin programma "proclamation, edict," from Greek programma "a written public notice," from stem of prographein "to write publicly," from pro "forth" (see pro-) + graphein "to write" (see -graphy).
The meaning "written or printed list of pieces at a concert, playbill" is recorded by 1805 and retains the original sense. The sense of "broadcasting presentation" is from 1923.
The general sense of "a definite plan or scheme, method of operation or line of procedure prepared or announced beforehand" is recorded from 1837. The computer sense of "series of coded instructions which directs a computer in carrying out a specific task: is from 1945.
The sense of "objects or events suggested by music" is from 1854 (program music is attested by 1877). Spelling programme, established in Britain, is from French in modern use and began to be used early 19c., originally especially in the "playbill" sense.
source

What is the golden rule for when to split code up into functions?

It's good to split code up into functions and classes for modularity / decoupling, but if you do it too much, you get really fragmented code which is also not good.
What is the golden rule for when to split code up into functions?
It really does depend on the size and scope of your project.
I tend to split things into functions every time there is something repeated, and that repetition generalized/abstracted, following the golden rule of DRY (Do not repeat yourself).
As far as splitting up classes, I tend to follow the Object Oriented Programming mantra of isolating what is the same from what is different, and split up classes if one class is implementing more an one large theoretical "idea" or entity.
But honestly if your code is too fragmented and opaque, you should try considering refactoring into a different approach/paradigm.
If I can give it a good name (better than the code it replaces), it becomes a function
I think you generally have to think of a chunk of codes have a chance of being reuse. It comes with experience to figure that out and plan ahead.
I agree with the answers that concentrate on reusability and eliminating repetition, but I also believe that readability is at least as important. So in addition to repetition, I would look for pieces of code (classes, functions, blocks, etc.) that do more than one thing.
If the name associated with the code does not describe what it does, then that is a good time to refactor that code into units which each have a single responsibility and a descriptive name. This separation of concerns will help both reusability, and readability.
Useful code can stick around for a long time, so it is important that you (or ideally someone else) can go back and easily understand code that was written months or years before.
Probably my own personal rule is if it is more than 2 lines long, and is referenced more than once on the same page (ASP.net), or a few times spread over a couple of pages, than I will write a function to do it.
I was taught that anything you do more than once should be a function. Anything similar should have a parent class, and above all else consult your source code "standards" within your organization. The latter mostly deals with formatting.
First, write the feature you're adding. (Notice the word "First", we tend to write a function/class before writing the feature, which might lead to having too many fragmentation).
Then, review the code you just wrote/changed, find what blocks of the code that is:
3-lines or more, and..
repeated, and..
Can be grouped under a named function. Because code is written by us, people (not programs), to be read/changed later by us, people (not programs).

Naming a function for provided localized strings

I'm putting together a list of function names for a function which would return back a localized string for a website I am working on. I'm still undecided what would be a good name for this function. My two goals are two try and make it as short as possible as I will have to replace tons of hardcoded text embedded in HTML but make it intuitive enough that new developers would understand what it is meaning. In many ways I think this is a personal preference but I am curious to hear what all of you folks would do.
Here's some example function calls of what I am looking at right now...
// This would return "Hello" for english, "Bonjour" for french
LangString("Hello")
// Same as above just different function name
LSTR("Hello")
I am working in HTML and embedded classic ASP/VBscript
I'd just use tr for translate. It's short, doesn't muddle the context too much, and it has a pretty universal meaning.
Qt and Unix use tr, at any rate, so it's not really a proprietary naming scheme.

Should HTML co-exist with code?

In a web application, is it acceptable to use HTML in your code (non-scripted languages, Java, .NET)?
There are two major sub questions:
Should you use code to print HTML, or otherwise directly create HTML that is displayed?
Should you mix code within your HTML pages?
Generally, it's better to keep presentation (HTML) separate from logic ("back-end" code). Your code is decoupled and easier to maintain this way.
As long as your HTML-writing code is separate from your application logic, and the HTML is guaranteed to be well-formed somehow, you should be okay.
The only code that should be mixed in markup-based pages (i.e, those that contain literal HTML) is the code used for formatting the HTML (e.g., a loop for writing out a list).
There are trade-offs whether you put the code in with the HTML or you use pure code to write the HTML out using quoted string literals.
No, if you want to build good and maintainable software, and to achieve loose coupling.
If I understand the question right, you're asking whether it's a good practice to mix markup with back-end code. No. While this is commonly done, it's still a bad idea.
You should read up on the MVC paradigm, as well as on existing questions on the matter, such as What is the best way to migrate an existing messy webapp to elegant MVC? and Best practices for refactoring classic ASP?
The point is to keep the display logic separate from the rest of the code. In any complex site you'll have code mixed in with your HTML, but the code should be for display purposes only. It shouldn't be doing any complex calculations.
For example, templates will contain loops and conditionals. Plus you'll probably have a library of HTML-specific routines, like printing out an <option> list based on a list object.
Imagine you were writing an application that has two output modes: HTML and something else. How would you write it, to avoid duplicating code? That will probably point you in the right direction.
The HTML that makes up the view has to get sent to the browser in some way. In .net, each server control emits its own HTML markup as part of the page lifecycle. So yes it is OK to use HTML in server side code.
Perhaps you should try following the ASP.net pattern. Create a bunch of controls that represent UI elements and make them responsible for emitting their own HTML based on their state.
Its fugly, and not type safe. But people do it without consequence. I'd prefer using a DOM or, at a minimum, classes designed to write HTML using type safe semantics. Also, its not all that good to mix UI with logic...
If I need methods that generate HTML I usually isolate them in an HtmlHelpers class. That way you keep some level of separation. The ASP.NET MVC Framework does this quite successfully.
If you mean printing out HTML in your code, then no. Unless you have a good reason not to, you should use templates
Even if you think you don't need this now, there's always a good chance you'll need it later. Maybe you want to output in a different format than HTML, or you want different presentation for the same data. You usually have the need for these things further down the road, so it's best to use one from the start.
I hate when developers print() a bunch of html. It's completely unnecessary and looks ugly in any text editor that shows print/echo strings in red.
I agree with everyone else that you should try as hard as you can to separate the HTML/XHTML markup from the application logic. However, sometimes you do need to generate HTML/XHTML in the application logic for various reasons.
In these cases what I have been trying to do is to ensure the bare minimum amount of presentation code is in mixed in with the application logic and try to migrate everything else over to the presentation code. It is worth nothing that is some cases you have situations where you could have everything moved over to the presentation layer, but it might be a bit easier to generate the markup as part of the application logic. In those cases, your best bet is likely to be to go the route that makes the most sense in terms of time.
I don't think there's any excuse for generating HTML inside your business logic. Don't even do it when it's just a "quick fix" or when you'll "go back and fix it later", because that never happens.
To reiterate my position from other questions, using some control logic (conditionals, loops) within HTML to construct it is OK. Do NOT do any data massaging or business logic in the HTML. You have to be disciplined, but it's worth it. Maintenance is much easier if your concerns (like logic and display) are separated.
Ideally you are aiming for a separation of concerns between your presentation (UI) code and your domain (business logic) code.
The reason why you should avoid coupling these two concerns (in either direction) is simple...
You will only have one reason to change a piece of code. whether this is from structural/styling changes in your html design, or from your business rules changing, you should only have to make the change in one place.
To a lesser extent, although many purists would disagree, by sprinkling HTML code through your domain code or vice versa you are creating noise for the next developer who comes along to read/maintain it.
I try to avoid using code to print HTML "directly". It is difficult to maintain, edit, add styles and etc. Some cases like generating an HTML email in the code, I create a text file or HTML file with markers like, [name], [verification code] and etc. I load this from the code and replace those markers. This way, you can edit the style of the email without re-compiling your code. Separating "presentation" and "logic" is a good practice in my opinion.
Mixing code within HTML is generally not a good practice in similar reasons as said in #1. However, I do use code in HTML for things like simple dynamic strings that are displayed multiple times on a page or pages. I think this is better than creating multiple server controls for same exact values to set. Since this is not code "logic" mixed in the HTML, I think this is ok.