Si … o no si ( To if or not to if )

Si … o no si ( To if or not to if )

Share it!Share on FacebookTweet about this on TwitterGoogle+Share on LinkedInEmail to someone
IT physical evolution has become clear, over the past years. Moore´s law is still being followed but its evolution has been sporadic and unequal. Most of the people know that languages as assembler has evolved to closest languages to the natural one, like Pascal, C or high level languages (java, .net, etc.)

Teclado

IT physical evolution has become clear, over the past years. Moore´s law is still being followed but its evolution has been sporadic and unequal.

Most of the people know that languages as assembler has evolved to closest languages to the natural one, like Pascal, C or high level languages (Java, .net, etc.)

Over the years new languages has been appearing. One of the most important advances in programming probably has been the language development geared towards the objects. Other paradigms of programming have tried to dethrone structural programming without archiving it. Although they have been able to settle in some kind of programming niches, mostly in academics and investigation. However we will talk about the pervasiveness if, which maybe is one of the most known structures.

This structure has been present over the different generations of the programming languages. Few people dare to challenge it although doing it is really helpful to create new bases.

At this point, there will be a lot of people who will wonder what is wrong with the if but argue about something that has been there permanently, as an axiom, probably will be the reason.

A practical exercise which may demonstrate that idea would be reviewing any control of source code, the section errors particularly and wonder:

How many errors have I had because of the if? How many errors would I avoid if I had added/ removed something?

A detailed approach will make us wonder where the if can take us to clarify the written code as the concept it is intended to transmit. Logical programming of the mathematics area covers the condition topic with more effort than a programming language.

Although programmers make big efforts to structure the code, massive quantities of if fill it, making it incomprehensive.

And it’s true that it’s unavoidable in some occasions. After all a is bigger than b, or smaller and it is not an impediment for this structure to be abused, especially when the code is designed. Rarely it’s necessary to create difficult structures using the if, current software patterns provide smart ways of code writing based on the typing.

Over the years, Factory patterns have standardized, which provide the creation of objects based on metadata, or common interfaces of the create types. It is not necessary in this case discern between each other, each one is conscious about its own nature, and can act in behalf of it.

We have a practical example in software testing. People used to say that it’s quite impossible to proof an application systematically because of the large quantity of variables and different data. Due to this, have emerged software metrics, and some methodology, oriented to the proofs.

If we stop in the white boxes proofs, we will realize that logical covering means a map code of the possible alternatives. This map is being built while the code is being branched. It’s obvious that a bigger number of branches produces a bigger number of proofs, and also a big number of mistakes.

These branches can be removed simply by a detailed inspection of the code, not only the current branch but also the previous code, which is very important as it will give a broader view of the code and therefore be able to discover all those unnecessary branches.

Often in software development global vision is lost over time, and consequently the quality of the software decreases due to example of advanced decisions were not subsequently checked. This causes loss of sight limitation in the new developments, develop new code without inspecting previous code which could provide valuable information on bifurcations “legacy” and that during development should be taken into account both for disposal to be considered in later code avoiding unnecessary branches.

This phase usually causes a snowball effect on the rest of the code, eliminating more branches. The interesting thing about this issue is the fact that this exercise is often not practiced because of the potential problems that could lead and the fact of repeat regression testing , when actually the code is being simplified on the testing level and now and in the future will be smaller and faster.

I, Arquitect
Josu Uribe Sainz

 


 

Use of cookies

This site uses cookies for you to have the best user experience. By continuing to browse this website you accept their use and agree to our cookies policy. Learn more about our cookies, following this link

ACEPTAR