Go Down

Topic: Architectural decision opinion (Read 788 times) previous topic - next topic

NJavrGuy

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: [Select]
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: [Select]


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: [Select]


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.

Erdin

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.

NJavrGuy

OK, thanks, definitely cleaner code that way

PeterH

What does the 'validation' consist of? It seems strange to have validation logic which does not return any information to the caller.
I only provide help via the forum - please do not contact me for private consultancy.

NJavrGuy


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: [Select]


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.

PeterH

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: [Select]

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.
I only provide help via the forum - please do not contact me for private consultancy.

robtillaart


my 2 cents:

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

Code: [Select]

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);
}

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

spatula

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.

Go Up