Verbose code is one that needs more words, or longer words, than is necessary to adequately express the intent of the code.

In verbose codes there are many very long symbols or symbols.

There is a chain that says that if the code is as close as possible to the natural language for the human, the more it will be readable. If this were true, languages would tend to do so more and more and COBOL would still be very successful for new projects.

There is another chain that says that the code is more readable if it is shorter if you can put more understandable code in the same field of view. I can not figure it out, but there are studies that indicate this, and it goes for anything.

It should be obvious that if you have distractions throughout the code, if you have too much information, or if the code gets too numeric (ciphered) by trying to shorten as much as it gives, it is not readable. You have to have the right compromise that gives the most expressiveness to whatever you do.

In some cases writing too much may even give you the initial impression of ambiguity. There are cases that encourage writing a code in a way that would fit another style.

Programming languages should always encourage the writing of the shortest possible code that is easily understandable, especially in situations where concepts end up mingling.

Question example

Why write function() { return 42; } when you can only write () => 42 ?

This is especially useful in cases where the function is passed as an argument to another function. It gets confusing to have a function inside an argument, it gets too long to read and there is no gain.

We use conventions to more compactly and possibly concisely indicate the same thing. So we eliminate the word function , which in this context is not necessary, return because the idea is that this form is very simple, that it only has a line and is always a return, and that having only one line, needs ; , and keys are not required for the same reason. But we've added => to make it unambiguous and show that it's the intention.

Short code

Do not confuse concise (non-verbose) code with as short a code as possible. It will not abuse one-letter variables, put everything together in one line, cut spaces, etc. just to look shorter, that's cutting the meat and not the fat of the code. The ideal is to write smooth code, that is, clean, if it heaps everything, it does not get clean.

It is understood that a mathematical notation is as expressive as a natural language notation if it is to express a concept that will be widely used, and because it is short, succinct, straight to the point, it is easier to read. Of course the person first has to learn that notation, but this is the easy part of learning to program.

What it does not do is compel the programmer to have to learn a new notation with each code base that it will move. In every language gives. Even most of the others copy, so it is rare for someone to come up with something very new, and usually brings what is already used in mathematics.

A less verbose code should always be clearer and more readable, not vice versa.

Example to see how easy it is to read:

var array = [1, 2, 3];
var quadrados = array.map(x => x * x);
var quadrados2 = array.map(function(x) { return x * x });

Of course who does not know the notation of the first one may not understand, but is a temporary deficiency of it , he learned , it is easier to read the smooth code.

Verb languages

Some languages are more verbose than others. They prefer words than symbols. They prefer to be more explicit than implicit (and have a better case). They prefer commonly used names that are long because it sounds more natural. Some adopt a style or paradigm that preaches more ceremony and demands things that are rarely useful in most cases to benefit the rare cases.

JavaScript was never very verbose, but it was a little, now it is modernizing to be less yet. CoffeeScript is a language that runs on top of JS which has as its main feature being very little verbose. Some find that exaggerated. When you exaggerate, you start giving room for errors or illegibility. There is something that seems exaggerated, but it has a function to be there.

    

The term "verbose code" refers to code that is longer than you would expect, either because the logic is too complicated or because the language itself requires it.

For example, in this case the two codes do exactly the same, but the second example is much less "verbose" and easy to understand:

Java:

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

Ruby:

print "Hello World!"

Typically the less verbose, the easier / quicker it is to understand the code (though not a rule).

More information about "verbose" languages: link

    

The expression verbose code is related to code that uses many lines to do something that can be done in less without compromising readability.

There must be a harmony between the number of lines and the difficulty of understanding the expected behavior.

In JS, more specifically ES6 the arrow functions can reduce the number of lines and keep the code readable.

// sem arrow function
let relatorio = {
  gerarPdf: function() {
    // código aqui...
  },
  gerarRelatorio: function(){
    document.addEventListener('click', function(e) {
      this.gerarPdf();
    }.bind(this));
  }
}

// com arrow function
let relatorio = {
  gerarPdf: function() {
    // codigo aqui ...
  },
  gerarRelatorio: function() {
    document.addEventListener('click', (e) => 
    this.gerarPdf());
  }
}

The example was minimal, but to have an idea of the readability improvement and still with reduction of lines