next topic »

[on:]

Hey everyone, I wanted to get some opinions on a decision I need to make.

I have a library which has a method say:

Code:

unsigned short int doSomething(unsigned short int param1)

This method has some code it will execute to do something.

I need some additional functionality, which is to validate that something was done, in doSomething.

I can do this in one of two ways:

The first I can see would be two separate methods:

Code:

unsigned short int doSomething(unsigned short int param1)
{
//Do the stuff
}


unsigned short int doSomethingValidate(unsigned short int param1)
{
        doSomething(param1);

        //write the code to validate that it was done here

}

OR I could do:

Code:

unsigned short int doSomething(unsigned short int param1, boolean toValidate=false)
{
//Do the stuff
   
     if(toValidate)
     {
         //write code to validate it was done
     }


}

Outside of micro controllers, I would ALWAYS use the second method, using one method with the optional toValidate boolean parameter.

However, I am wondering if the if logic I would need to write in that method would be too much overhead, considering this method will be called a tremendous amount of the time, and I will always know when calling it whether I need to validate it or not.

I would be curious to know if there are best practices in this case, or just some general opinions.

[Reply #1 on:]

Use the second one, let the compiler do the optimizations.

But if timing turnes out to be a problem, you could rewrite specific parts. But you have to know a few things:
- A mathematical division is slow, with integers and float.
- Handling 8-bit variables is a lot faster. For calculations and for the stack.
- The new Arduino Due is faster.
- Some Arduino functions are slow. You could write the registers of the internal timers yourself. But be careful that it doesn't conflict with the Arduino code.

[Reply #2 on:]

OK, thanks, definitely cleaner code that way

[Reply #3 on:]

What does the 'validation' consist of? It seems strange to have validation logic which does not return any information to the caller.

[Reply #4 on:]

What does the 'validation' consist of? It seems strange to have validation logic which does not return any information to the caller.

The idea is this:

Code:

unsigned short int moveToLocation(unsigned short int location, boolean toValidate=false)
{

//call method to get to target location

if(!validate)
{
  return 1;
}
else
{
  if(atCurrentLocation)
     return 1;
  else
     return 0;

}

}

It's way, way more complicated than this, but this is the concept in a nutshell.

[Reply #5 on:]

If the 'validation' is cheap (relative to the rate at which this function is being called) then I'd do it regardless and just ignore the return value when not needed.

If the validation is expensive and often not required then I'd provide a separate method to do the validation. For example:

Code:

void setLocation(unsigned short int location);
unsigned short int isAtLocation();

Note that the extra runtime cost of doing the validation would have to be significant (i.e. causing me a problem) before I went to that bother and complexity of adding the code to avoid it.

[Reply #6 on:]

my 2 cents:

make an object that encapsulates the functions, it can have an internal state that represents its current location.

Code:

object.setLocation(location)
{
    // do all things ....
  _location = location;   // _location is private member of the object, it remembers the last location
}

object.isAtLocation(location)
{
  return (_location == location);
}

[Reply #7 on:]

I think it mostly depends on whether validation is just for error checking or provides some feedback, e.g. if the object didn't move it may be because of an obstacle requiring some action. It is often useful - when possible - to return a value instead of a void (e.g., the current value of a variable that should have changed). This value can then be examined to see if the action was successful.
Generally speaking, having two separate functions (first approach) gives you more flexibility: you can turn out validation or change your validation method without affecting the functional part. The most important reason why I would follow the first approach is that it keeps a clean interface (the method signature doesn't include parameters that are not needed to perform the intended function).
Semantically, 'validation' is usually an external procedure, while 'verification' is (usually) something performed internally.