Another style pet peeve

Here is another pet peeve people might do when program:

if(A) {

    if(B) {

        somecode1();

    }

}

Who knows, it might not matter the compiler, but for human readability sakes never do this, there really shouldn't be an excuse. Maybe for when debugging but in that case clean it up before you show it to the world.

Just write it as this:

if(A && B) {

    somecode1();

}

please...

Ok, so why write it as the latter? Well Personally every time I see nested if statement I think there is a reason for the nesting. There could be code at the start of nesting or at the end of the nesting, I can't tell at first glance, I must pay attention to those details, which is not something I'm good at, it also takes more time to investigate which of the damn closed nesting statements corresponds to which. Plus with more nesting = more text on the screen = harder to read.

Just remember that reading other peoples code is one of the hardest thing for a programmer to do, so the more to the point the code is written, the easier it is to read and understand (the whole point of reading).

how not to branch

As I work on code at work I see a constant theme, one that drives me crazy if goes like this:

for(A){

    if(B) {

        somecode1();

        if(!C)  {

            somecode2();

            if(D || E) {

                somecode3();

            }

        }

    }

}


As you can see it's starting to look like a Christmas tree which isn't very readable. Instead one should write (or refactor) the above code to look more like this:

for(A){

    if(!B) continue;

    somecode1();

    

    if(C) continue;

    somecode2();

    if(!D && !E) continue;

    somecode3();

}

My instructor in college (Dr. Hunter) referred to these as sentinel statements, or something like them. Nesting is not the easiest way to read code and betrays organization. One intends that somecode1-3 gets called in order unless some of the conditions occur. Putting them all in the same indentation gives the reader of your code that impression, by placing code in a nest it's as if your saying "hey this code is one part that could be run, but isn't necessarily what the point of this method is" So I say, indent the optional code, don't for intended code.

a strange thought

As I sit here at my desk at work too annoyed to do anything productive, yet too bored to do other wise it struck me how odd it is what I do. I have my development studio open  (yes visual studio, YUK) I realize that I have a code window open that is split in two with a break point across each pane,  book mark and a disabled break point. I just imagined that to a person not used to programming that this mess would be complete gibberish. Yet I am completely at home, completely familiar with the mess. The split screen actually make it easier to do my job while at the same time makes the screen resemble a cockpit from a 747 with too much going on to pay attention to.

I <3 what I do

I <3 who I am

and yes, I am a geek :D

Integrator blues

So, here I am working on the Drive train for Rigs of rods and I've got a conundrum. My typical approach to forces and integrators is that when you add a force to an object you expect it to last for the size of the time step, any longer and what ever added the force needs to keep adding it. Perhaps I should still keep to that principle.

Here is my problem, I want to hide the integration stops from anything interacting with the integrator. This comes to be a problem (for me anyways) when getting into higher order integrators such as the Runga-Kutta K4 (4th order). It seams that any integrator higher than 1st order requires steps smaller than the given time step, for example, RK4 takes 3 extra euler steps for every integrator step, it takes two steps at half the time step, and one at the full time step.

lets setup an example:

class object {
    float force;
    float x;
    float v;
public: 
    //! apply constant force for the next integration step
    object() : force(0.0f), x(0.0f), v(0.0f) {}
    void applyForce(force(float force) { this->force += force; }
    void integrate(float dt) {
        x += v*dt;
        v += force*dt;
        force =0.0f;
    }
};

so say you have two of these objects coupled together by a spring (f = -kx) now RK4 is basically

1. Get derivative @ t=0, k1
2. Advance dt/2s using k1, get derivative k2
3. Advance dt/2s using k2, get derivative k3
4. Advance dts using k3
5. Advance dts using a weighted average of the difference derivatives (k1 + 2*k2 + 2*k3 + k4)/6

Notice 2 half steps and 1 full step. When dealing with multiple bodies you can't run through steps 1-5 for each object, you need to do step 1 for all objects, steps 2 for all objects, etc.

Lets say you have a sim of with a time step of 0.001s, you have an external system that adds 100N to the object. the 100N is to be applied for 0.001s while the force from the spring needs to last for 0.0005s, then is recalculated again.

Perhaps, forces need to be distinguished between static forces and dynamic forces. Static forces are forces that depend on user input, for example a car engine, mouse movement, etc. Dynamic forces are the internal forces generated by the physics simulation. In other words Static forces are applied and last an entire time step, dynamic forces are calculated on the fly when requested.


Hmm, while typing thing I wonder an approach similiar to Ogre frame listener would be appropriate. calsses that effect an object can be registered as a "FrameListener" of sorts, there are calls to each listener that signal the start of the tiem step calculation, and one at the end of the calculations, and perhaps each intermediate time step when using higher order integrators.

Food for thought, but perhaps at a later time.