2

I have a function to show or hide a certain UI control. In my example case below, the framework is jQuery I'm using for an event to show a tool tip that may fire a LOT (based on mouse movements) - but the underlying problem is more general and may also arise in a similar manner in lots of other UI frameworks. In fact, the problem could be even more generalized to any kind of component with two states to be switched often, not just UI components.

Consider:

Code A:

$(this).plothover(function(item) { 
   if(item&&item!="undefined"){
      show tooltip
   }
   else 
     remove tooltip
});

Code B:

$(this).plothover(function(item) { 
   if(item&&item!="undefined"){
      show tooltip
   }
   else {
      if(tool tip is shown){
           remove tooltip
      }
   }
});

item will exist at defined Cartesian points where datapoints exist (ie, graph coordinates on a canvas). In other words, the odds are ~10000:1 in the favor of the else condition firing on a DPI basis.

As the mouse moves,

Code A removes it with no regard to any condition Code B only removes it if it was already created, but has to test the creation first

So, which is considered 'right'? Blind hide the control whether it is visible or not, or only hide it if it is visible?

I've benchmark'ed it through jsperf and the differences are negligible performance wise but does lean towards the blind destroy. But if it's 'wrong' by theory to do it, i'd rather chose the best practice route.

--- EDIT --- To clarify, The actual invocation is not important (ie, how is it removed). Nor am I looking for a code review. The above given example is one of many times I've run into this case.

Rather, I wish to discuss the theory involved in "Destroy what may exist" or "search and destroy if it exists".

  • By 'remove' you mean setting style.display = 'none', yes? I would prefer the first option, just because it makes for shorter code, but I don't think there are any clear-cut arguments for either case here. In some other case, where the "remove" operation is not idempotent, or would throw an exception, you would of course have to test before removing. – Mihai Jan 13 '15 at 20:25
  • Also, I don't think the programmers stackexchange is the best place for this question. You might want to try codereview.stackexchange.com – Mihai Jan 13 '15 at 20:28
  • 1
    @Mihai Migration to Code Review was rejected because the question contains hypothetical pseudocode. We would be glad to have the author a similar question on Code Review with a fully working example. – 200_success Jan 14 '15 at 1:54
  • 1
  • 1
    @WorldEngineer: I changed the question a little bit to make it more appropiate to programmers. – Doc Brown Jan 14 '15 at 8:55
0

Here's my post from Code Review I posted before the question got closed there:

Why test in the first place? When you are trying to avoid an expensive operation, one that is significantly more expensive than the test itself.

Your performance gain comes from selectively calling remove and gaining the time not spent always removing it.

So your answer is, given 2 actions, test and remove, and p the probability of the tooltip being shown, test and remove when time(remove) > time(test) + p * time(remove).

Which is exactly why how it's being removed matters.

1

When there are two equal alternatives to implement something, where one needs more code and the second less (and "less code" is indeed simpler, not a "clever hack" which stresses your mind), I would typically prefer the simpler one over the more complicated. Easier to read and understand, easier to maintain, easier to change.

Of course, in a case like the one shown above, you have be sure that the API of the component you are using allows to apply "remove" regardless of the tool tip to be shown before, and that you can really leave out the test without introducing a bug (if the API design is sane, one could IMHO expect that, but not all APIs are robust). On the other hand, adding a test like if(tool tip is shown) though it is not needed shows that you did not understand the API fully and leaves you with a bad example if you are going to write a similar code snippet later again.

0

You have design-patterns(composite,memento,singletom ...), you have principles of OOD (SRP,Dry,LSP ...) and you have tactics (CJ, Paranoid, NAG ...). The two examples follows different tactics.

Tactics decide if you need performance, logging or readability. They are typically specified by the senior developers or CTO.

Because you say performance is negligible and its Javascript, so we are in View of MVC and you are near to the User i would advice this NAG style (also lets use OOP a little):

function ToolTipAppearanceManager(){
  /** @param show {Boolean} <code>true</code> to let it appear, 
   *                        <code>false</code> to hide.
   */
  this.setVisible = function(show){
    if (show){
      if (tool tip is shown) {
          if(console && console.warn)console.warn('Already visible. Maybe bug!');    
      }
      show tooltip;
    } else {
      if (not tool tip is shown){
          if(console && console.warn)console.warn('Already removed. Maybe bug!');    
      } 
      remove tooltip;
    }

  }
}
var appMan = new ToolTipAppearanceManager();
$(this).plothover(function(item) {
   appMan.setVisible(item && item != "undefined");
});
  • This way its in the full responsibility of the ToolTipAppearanceManager what to do: Alert or Ignore. – Peter Rader Jan 14 '15 at 14:26
  • You deal with this case as if it is a potential bug to call "remove" when the tool top is not visible. From the description of the OP I was under the impression quite the opposite is the case, and the code above might dump tons of unneccessary warnings to the console. – Doc Brown Jan 14 '15 at 14:29
  • @DocBrown Sometimes it is neccessary, in example if the removal takes hours of work. See, using the mememto-pattern this may critical if no changes has been made between two mementos, therefore you may like to see a I added the state but nothing has changed!. – Peter Rader Jan 14 '15 at 14:35
  • To cite from the OP's question: "the differences are negligible performance wise". I thoght even when we generalize from the actual example, we are still talking about such a case. – Doc Brown Jan 14 '15 at 14:38
  • @DocBrown if i write a @DocBrown at the start of the comment, you know its for you ;D – Peter Rader Jan 14 '15 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.