Wait…just reread the question…I assume that liabilities and equity are values retrieved from the DB?

If liabililities and equity have to also be calculated from other data, then I would create three functions – two functions that calculate liabilities and equities, than pass those two functions as parameters to a third function that does the division of those two.
That way you have all of that information organized, and can pass just pieces of it around if needed.

For example, you could then display a nice message saying:

[B]Your total liabilities:[/B] < liabilities function >
[B]Your total equity:[/B] < equities function >
_________________________________
[B]Total Debt to Equity: [/B] < the third function >

A more fleshed out example of the above would divide the params up to the child functions that need them, in addition to returning 0 rather than attempting a division by 0.

I can see passing the results of a function to a more general one, but if you start sticking one function in another, then why not just have one huge function?

That looks like a winner to me. It’s a little more work than writing one large function, but I’m sure you will need to itemize this for visitors anyway, so my as well kill two birds with one stone

Let’s go back to basic arithmetic and refactoring. Consider the polynomial

2x[sup]2[/sup] + 4x + 2

Before factoring out this expression we can divide all terms by 2 to arrive at

2 (x[sup]2[/sup] + 2x + 1)

From here it’s a bit simply to factor out the polynomial

2(x+1)[sup]2[/sup]

So what does this have to do with computer functions? Computers are math and work much the same way. Each expression can be thought of as a function. By keeping them discreet they can operate on each other, or even on themselves which is known as a recursive function.

It is no accident that tidying up code is often called “refactoring” it, and refactoring, strictly speaking, is done with polynomial expressions. They are done for the same reason - to keep each statement about the equation in one place. It takes less time to solve f(x) = 2(x+1)[sup]2[/sup] than work through the unrefined version of f(x) = 2x[sup]2[/sup] + 4x + 2. Let’s take a look at it when x = 5.

The two polynomial functions are equivalent, but the later is more efficient. This is why it is crucial in high performing code to define each step of the process once. Also, it’s easier to perform a transform on f(x) = 2(x+1)[sup]2[/sup], but that’s outside the scope of my math skills (conceptually I get it, but my practice is sadly lacking).

Aside from computational performance, it’s easier to maintain a program where everything is stated only once than a program where things are restated multiple times, and often in slightly different ways. Avoiding repetition is known as DRY (Don’t Repeat Yourself) coding.

My theory is, is that people tend to overthink things, and ultimately make things more complicated than needed in the process. I am certainly not implying that your post is an example of such; merely making a general observation as it pertains to the thread, and our tendencies in general.

How this post does relate though is the part about adhering to DRY principles, and indirectly, structuring the application. I proposed simply making three seperate functions, because to me, it seems that we keep ourselves DRY by having two functions that perform two unrelated (but necessary) calculations, and a third function that provides the ultimate information being seeked. With all three functions being seperate entities, and very small and simple ones at that, it lends itself very kindly to future refactoring should it ever be required, but still gives us the flexibility to display these small nuggets of information by themselves when they are needed – which can’t be done if we had just stuffed this whole operation in one function (or at least not sanely, hehe…).

It is slightly more work doing it that way, but as far as I can see, I think the benefits are worth a few extra lines of code

Both in math and computer science functions are high level operations. They are also defineable. Multiplication after all is shorthand for repeated addition. Exponentiation is shorthand for repeated multiplication. A function is therefore a shorthand for a specific sequence of operations that, once defined, can be referred to by that shorthand rather than write the process out each time it is used. The shorthand can itself be taken as an operation.

Consider f[sup]1/sup = x+3 and f[sup]2/sup = x*3. What is f[sup]1/sup when x is 5. 18. Can we simplify the functions? Yes, and the rules for doing so are the entire area of mathematics called calculus.