After learning, coding, and coding even more than ever now, I have noticed a trend in a lot of programming which I do. The trend is that the majority of my functions are if{} or if{} else{} statements when it comes to performing the functions in my code.I narrowed out the option of it just being the project which I am working on. The project is building a PHP Framework or Application (whichever you want to call it). The vast majority of my code for the autoloader.php, application.php, and all of the heavy-lifting files are performing their functions of making sure everything loads correctly and builds the environment.After working with very complex functions within my code to do this and that, they are all wrapped within an if{} or if{} else{} statement.Is this a common trend for the majority of programming? Or am I over reacting to something which I am seeing a lot of? Does the most complex functions in coding always go back to the basics of the legendary if{} or if{} else{} statement?
All programming functions always return to the If or If/Else statement?
design;design patterns;programming languages
There are multiple ways to look at this question.How the conditionals are usedThis is probably more the question you asked. And the answer is, it depends on a number of factors. For folks that heavily use SQL, the end up having queries often built in a way (e.g. using WHERE or HAVING clauses) that the code does not need if conditions. However, those conditions have just moved into somewhere else and look different. Therefore, it becomes an organges to apples comparison.Some developers will tend to write more conditional code while others may use declarative expressions (such as LINQ in C#), in which the Select, for example, already embodies conditionals.And lastly, sometimes it's just a personal style. For code clarity, I prefer not to write nested conditionals, and thus end up distributing them elsewhere. In many cases, I reduce the conditionals by using patterns, such as Adapter or DataMapper which pushes conditional in one place and the rest of the logic flows depending on which class was instantiated.Code complexityThere are some metrics, such as cyclomatic complexity (also known as conditional complexity) that will attempt to estimate whether the code is too complex to be maintainable (and thus considered bad). For the reasons I mentioned in the previous section, and by spending a fair amount of my career in test discipline testing others' code, I can tell you that it's hard to generalize this one too, and thus opinions vary on these metrics, even within the test community. Howeve, you can read more on these and some tools, such as Visual Studio, will give cyclomatic complexity and sometimes you can try to improve it and see if it helps with code organization. Sometimes, such 'prototyping' does help.Principle of conditionsIn principle, if/else conditions (and all of its sisters) are really making one or more decision. That decision could be because the program actually needs to make a decision on user's behalf (such as deciding whether to include a transaction for a balance sheet, etc.), or a decision for internal program logic (e.g. based on screen resolution, deciding whether the flow is multi-column or single column).Thus, in general, quite a bit of code can look conditional, and no one can state whether there is anything wrong with it (or not).ConclusionIn my opinion, code organization is some art and some science. I learnt the art part just by coding for a living for a major part of my career, and the science part by learning through books, code reviews, etc. I do not think anyone can achieve one without the other. Your best bet, if you are concerned about your code, is to convince someone to do a peer review of your architecture, design, data model and code. An outsider, especially someone who hasn't worked with you, can sometimes even bring a perspective that you cannot easily payback. But you can return the favor to them (or someone else).