Style preferences in for loop structure

Started by
22 comments, last by Khatharr 7 years, 7 months ago

Speedwise, get rid of the conditionals in any way possible (even - or especially - if this means restructuring your data).

Branches in for loops are bad juju. They typically play very very poorly with branch predictors. Branch prediction is a _massively_ important part of how CPUs work; they're up there with cache access pattern in terms of "hardware crap you really need to understand and think about" when writing games (or any application, imo - even if raw speed isn't important to you, saving on energy costs is hugely important in mobile and server workloads)....

I completely understand and respect your argument against branches in loops. I mean I've designed and built computer systems on the circuit level and understand machine cycles, energy consumption, registers and such, but don't you think that "branches in for loops are bad juju" is a bit excessive for the general case? If you're iterating over 300,000 objects, then I can see where you can shave off a substantial amount of time eliminating branches. However, with today's PC hardware standard, would looping through 10 or 15 items with branches make a difference you should care about?


It isn't just the performance considerations. Pre-sorting objects to iterate through them without conditions simplifies the code, as well. You can look at a piece of code and know exactly where it's going to go just by looking at it. That (usually) makes it easier to see what a given piece of code is supposed to do in addition to what it does.

// this is annoying to read and debug - I have to step through the loop to see what kind of entity I'm on at any given type
for (auto& e : entities)
{
   if (e.type == boop) { // ... 
   }
   if (e.type == snoot){ // ... 
   }
}

// this is better
for (auto& e : boops)
{
  // ...
}
for (auto& e : snoots)
{
  // ...
}
Advertisement

but don't you think that "branches in for loops are bad juju" is a bit excessive for the general case


I speak in absolutes like every single other millennial. I exaggerate and over-emphasize _constantly_, too. It's the worst thing ever.

Sean Middleditch – Game Systems Engineer – Join my team!

Forget the body, what about the fist line? :wink:


for(int i = 0; i < MAX; i ++)
VS idiomatic iterator style:

for(int i = 0, end = MAX; i != end; ++i)

The for loop is everything wrong with imperative code imho :)

It has too many moving parts and too many ways to make stupid mistakes. Much prefer the declarative approach C# allows with something like this

Range(0, MAX).Foreach(i => {do stuff here});

and to filter

Range(0, MAX)

.Where(i => someCondition)

.Foreach(i => {do stuff here});

Easier to read and reason about and really hard to mess up :)

The only problem with the C# Linq style is that it is significantly slower if you get into a performance critical tight loop. (https://jackmott.github.io/programming/2016/08/20/when-bigo-foolsya.html) I'm not sure how much of that is inherent versus implementation-specific, but it is something you may need to think about.

Eric Richards

SlimDX tutorials - http://www.richardssoftware.net/

Twitter - @EricRichards22

[


if (condition == true)
...
if (condition == false)
vs.

if (condition)
...
if (! condition)
Back in my unexperienced days, I would use the latter because all the cool kids were doing it :cool:, but I'm find myself using the first form a lot more to make it easier to read. The more I code, it seems the more I work towards readability.

That suggests that you're naming your variables poorly. A properly written if() should read similarly to English:


if(dude.isAbiding()) { ... } //"if dude is abiding" ...

if(!moving) { ... } //"if not moving" ...
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

This topic is closed to new replies.

Advertisement