There are multiple ways to look at this question.
How the conditionals are used
This 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 complexity
There 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 conditions
In 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).
Conclusion
In 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).
ifstatement and there is certainly nothing wrong with them. You could be over-using them. Or maybe you just need them. You're asking for a generalization in order to prove a specific example. – Brandon Jun 22 at 2:10ifs, often quite noticeable in C and Go programs. If you're not afraid to read long articles using unfamiliar languages, but with nice pictures, try reading "Railway-based programming" which explores this pattern and shows a way to tackle the problem, in a way common to functional programming. – 9000 Jun 22 at 3:47