Exit points or a little bit about structured programming

When reading Habrahabr or looking at other people's source codes, I often have to notice something like the following piece of code that sounds the same in any language, no matter what is written:

function (single_document)
{
if (single_document.getElementById ("comments")! = null )
return ;
...
...
...
...
} * This source code was highlighted with Source Code Highlighter .

Here is a piece of Javascript code, but you can write the same in several dozens of other languages. What is wrong here? Only that the function (method, properties, procedures) has several exit points. If you wonder why this is bad, read what is written under the cut.

Of course, each programmer has his own handwriting, which imposes a character on the written code. A sloppy programmer writes casually, a neat one adheres to the rules and writes code that is a pleasure to read. And not only to read, but also to support accompany, change. On the other hand, the programming paradigm is changing a lot and the principles already described by Dakeshstroy , Knut and Wirth are a bit outdated, sometimes they do not fall under the format, they are simply not applicable in places. But, the fundamentals, the foundation of structured programming will always remain as long as the practice of divide and conquer is alive.

Thank God, you’ll almost never see the use of the goto statement in the code, although this happens. But more often, many other less obvious principles of structured programming are not followed. One of these principles, attributed to Edsger Dijkstra , is:

“A module (in this case, a function) must have only one entry point and only one exit point”

')
In this regard, the use of the return statement in the given example contradicts the principle of structured programming. What is so good about this principle?
The reasons for following this principle are as follows:

• the difficulty of debugging such a code, it is not always obvious when a return from a function occurred, for example, we have several return and we can never say exactly which of them was called;
• problems with maintenance and change. When looking at the code, especially if it is large, existing exit points are not always visible. In this regard, the behavior of the added code can be unpredictable, it is not known for certain whether your added code will be executed at the end of the function or not. In order to be sure of this, you need to unambiguously evaluate all exit points, understand the logic, and perhaps implement a challenge of your code before each exit point.

For two reasons, for me personally, it is enough for me to abandon the simple solution of interrupting function code in several places. Experience has shown that the habit of reducing the code to the above structured programming principle is only beneficial, does not limit the programmer in any way and contributes to writing more readable code.

How to rewrite the presented code:

function (single_document)
{
if (single_document.getElementById ("comments") == null )
{
...
...
...
...
}
} * This source code was highlighted with Source Code Highlighter .

The presented code is minimal in meaning and content, you need to understand that it is intended to show the principle, and not to demonstrate the result. Many may say that a single return from a method or function at the very beginning of a code is a common practice and that there are no problems and that it is always used. I will not discourage, but I would like to remind you that the principles and principles to adhere to them always, and not just on demand. Firstly, it brings up, secondly, in some way improves the code, which will always be built on the same principles, without violations. And thirdly, the habit of writing correctly is what everyone should strive for, isn't it?