Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

JimNayzium's avatar

General Coding Efficiency Question for Y'all

I constantly go back and forth mentally on which way to do things when it concerns choices like this. In this example, let's assume this tiny little calculation occurs thousands of times when a class is instantiated.

Is there a "best practice" when it comes to this type decision? Or is it always going to be our own coding personality deciding just how much to care about efficiency vs readability?

$a = $A === $B;
if (!$a) {
    return false;
}

$b = $B > 0;
if (!$b) {
    return false;
}

$c = $C === 0;
if (!$c) {
    return false;
}

return true;

Versus this, which seems to communicate clearer and feels more readable, but makes all three calculations every single time.

$a = $A === $B;
$b = $B > 0;
$c = $C === 0;

return $a && $b && $c;

I lean towards the first one as I write the first versions of things, and then when refactoring find myself updating many of my functions' verboseness to things like the latter version. But I always wonder just how much efficiency is lost when these decisions are multiplied out over a months' worth of changes! 😄

0 likes
9 replies
LaryAI's avatar
Level 58

When considering efficiency versus readability, it's important to weigh the context in which your code will run. In your example, the choice between the two approaches depends on the specific needs of your application and the frequency of execution.

Efficiency Considerations

  1. Short-Circuit Evaluation: The first approach benefits from short-circuit evaluation. It stops evaluating as soon as one condition fails, which can be more efficient if the conditions are computationally expensive or if the likelihood of failure is high early in the sequence.

  2. Redundancy: The first approach avoids unnecessary calculations if an earlier condition fails, which can be beneficial in performance-critical sections of your code.

Readability Considerations

  1. Clarity: The second approach is more concise and arguably more readable, as it clearly communicates that all conditions must be true for the function to return true.

  2. Maintenance: Readable code is generally easier to maintain. If the logic is straightforward and the performance impact is negligible, favoring readability can be beneficial.

Recommendation

  • Profile Your Code: If this code is part of a performance-critical path, profile both versions to see if there's a significant difference in execution time. Use tools like Xdebug or Blackfire for PHP to measure performance.

  • Contextual Decision: If the conditions are simple and the performance difference is negligible, prefer the more readable version. However, if this code is executed very frequently and performance is a concern, the first approach might be more suitable.

  • Balance: Often, a balance between readability and efficiency is ideal. Consider adding comments to the first approach to improve its readability if you choose it for performance reasons.

Here's a slightly modified version of the first approach with comments for clarity:

// Check if $A equals $B
$a = $A === $B;
if (!$a) {
    return false;
}

// Check if $B is greater than 0
$b = $B > 0;
if (!$b) {
    return false;
}

// Check if $C equals 0
$c = $C === 0;
if (!$c) {
    return false;
}

return true;

Ultimately, the decision should be guided by the specific requirements and constraints of your project.

martinbean's avatar

@jimnayzium It’s a moot question, because the idea of coding is to encode business logic. No one can possibly say what’s “good” or “bad” about doing a load of operations on As and Bs and Cs, because you’ve removed any and all context from whatever it is those variables actually represent.

1 like
JimNayzium's avatar

@martinbean apologies. I thought this:

"In this example, let's assume this tiny little calculation occurs thousands of times when a class is instantiated."

was enough context to at least get at the concept of what I was asking.

I think my level of expertise can be summed by me confessing I don't even truly know what you mean by

 because the idea of coding is to encode business logic

😄

martinbean's avatar

In this example, let's assume this tiny little calculation occurs thousands of times when a class is instantiated.

@JimNayzium And why would such a calculation occur “thousands of times” when a class is merely instantiated…?

It’s impossible for people to give you concrete advice for such vague questions. All you’ve done is: “I have some code, but I’ve removed any and all context and instead just present a load of As, Bs, and Cs. How can I objectively make my code better?”

Vague questions get vague answers. If you want more specific answers or advice, then present the actual problem and not pseudo-code. A, B, and C means nothing to any one, nor does it tell you what operations you’re performing on those variables or why.

1 like
Snapey's avatar

your code is as meaningless as

return $A === $B && $B > 0 && $C === 0;

which also benefits from short-circuit evaluation and does not create pointless temporary variables

1 like
jlrdw's avatar

Also mostly refactoring is for us humans the CPU could care less how sloppy the code is. It's gonna crunch the code anyway.

Is procedural code anyway at CPU level.

I would suggest watch Jeffrey in much of his code how he does refactoring.

And many times he will state it will work either way. But the refactoring is just nicer code.

1 like
JimNayzium's avatar

@jlrdw This is what I was mostly asking. Thanks for your thoughtful response!!

I realize I broke it down so simply that it removed a little of the point I was getting at.

@snapey, yours feels like a super elegant solution to me! (But often the $A and $B and $C will consume multiple lines and feel gross if written all out like that, but in this instance, it's a wonderfully elegant different way to go!)

I guess I was asking more of the an architecture question as a novice level coder.

When we are faced with the necessary logic that three or four things determine the outcome, and all four of those things take a very tiny amount of CPU power to calculate, BUT those things could feasibly be executed thousands of times each time that method is called and that method is called thousands of times in an operation loop, as a concept, SHOULD we always be looking for the short-circuit/early return?

That's more the concept question I was getting at.

I feel like I spend a lot of "time stressing" over re-writing a function if I don't FIRST utilize the earliest return possible, but my hunch is I don't need to be stressing it that much. (But then I don't want to stop stressing it if stressing it was actually the BETTER practice!)

FrancescoDiMuro's avatar

@JimNayzium

When we are faced with the necessary logic that three or four things determine the outcome, and all four of those things take a very tiny amount of CPU power to calculate, BUT those things could feasibly be executed thousands of times each time that method is called and that method is called thousands of times in an operation loop, as a concept, SHOULD we always be looking for the short-circuit/early return?

I guess that's A way to program, but that's not the only way. For sure, having a programming style where you avoid to evaluate variables or check expressions in different else...if, that probably lets you run less code, and avoid to nest it so much.

Being saying that, you choose your style of coding, the one you're more comfortable with. Experiment the different styles and see which one fits you better.

2 likes
jlrdw's avatar

@JimNayzium I also program in python, not data but metal layout routines.

And yes some small layout is quick, but some complex layouts are more time consuming.

In fact some of the routines were original done in BASIC. You need not worry about a second or two.

Example:

A large quarterly accounts accounts payable report is going to be slower than a query pulling in one customer.

Some days in my bank the account is pulled right up. Other times and you may had herd it also, the teller saying the system in slow today. So big deal I wait 3 or 4 more seconds.

Some large companies actually let large reports run over night, they have tens of thousands of payables and receivables.

Index correctly and query only what's needed and you are good to go. I have done this stuff since the late 1980's starting with dbase 3 and never a major problem with a second or two difference.

High internet traffic can even slow things down at times.

2 likes

Please or to participate in this conversation.