Get rid of the "(no error)" part of the error cluster

[tst]

There's a common convention in LabVIEW where if a control is not a required input, you place the default value in parentheses:

 For the most part this make sense and is useful when calling VIs, but there is one place where it's really annoying:

We know there's no error by default. I suggest that NI simply remove this. This can be done today by going to <vi.lib>\errclust.llb and modifying the control, but that's annoying to do with every installation.

I would even go so far as to say that NI should write a VI which will go through vi.lib and remove the text from all the existing VIs. I doubt this would have any backward compatibility issues, because I think the only place where those would be relevant is if someone is calling a VI in vi.lib dynamically AND setting the error in value, and frankly, those people deserve to be punished.

[altenbach]

> However, I do very much like the idea proposed by altenbach of changing the rule to not have the default value if it is different from the default for the datatype. 

Hmm..., that's the exact opposite of what I said. Right? Maybe I am confused....

[tst]

> ...that's the exact opposite of what I said

It is, but you should note that your proposal isn't actually an Idea, only a convention change. The second idea I posted should handle this issue (and I did mention there it should take empty data into account. I'm not sure about default data, but that's also a legitimate view).

[Ray.R]

I guess I'm not the only one that deletes the "(no error)" from the cluster name.

Kudos!

[jmorris]

Um, yes, what I wrote was the exact opposite of what you said, and what I meant.  I liked that part of your idea - not have the default value if it is NOT different from the default for the datatype.  Or, more simply, only have the default value if it is different from the default of the datatype.  Silly double-negatives.  😉

[CrystalTech]

NI... I have one better!  Make only one Error Cluster to choose from, and have the label print out "Error In" or "Error Out" automatically depending whether it is a control or display.  I also follow the convention that if the control value is a default value of the control ( e.g. Int (0) ) I do not list the number on the label unless it is greater than 0.  Which follows, "Error in (no error)" ...no error is already understood, so it does not have to be there.  Tst, your idea is definately a Kudos.  Thanks.

[Karsten_Dallmeyer]

I don't like this idea. It breaks with the LV style guide.

[tst]

> It breaks with the LV style guide.

Well, that's because the style guide is based on the current behavior of LV. NI needs to implement the other idea (Show the default value of controls in subVIs which aren't required in the tip strip) so that we don't have to do this manually. Then it will apply to all controls and not just the error cluster and the style guide can be fixed appropriately.

P.S. Personally, I don't care what the style guide says. It's a set of recommendations, some of which I follow and some I don't. This is one example where the general guideline which I happen to agree with (show the default value for optional controls) clashes with a specific control where an exception needs to be made.

[soupy]

I agree. this breaks style guide, so it isn't good. I think that the golden rule is that "consistency is correct". Implementing this would break consistency, for no direct benefit, so it is bad.

You should always explicitly indicate the default value on non-required inputs even if they are standard defaults. This bit of text shows that you went through the though process.

I think this idea highlights the misconception that visually larger code executes slower. You should focus more on the code function and get over the misc visual things that invoke the ADD in us all. 

[tst]

> I think this idea highlights the misconception that visually larger code executes slower

How did you reach that conclusion? I proposed this idea because the no error text is both annoying and unneeded, and I didn't see anyone else who suggests it hurts performance (although, in all fairness, if you have to allocate or compare a longer string, that would take longer, but that's completely negligent).

If it helps, I think the other idea is worth a lot more than this one, because it will save actual work and make code more readable. Once it's implemented, you wouldn't need to provide default values and then you shouldn't care if NI decides not to include the default value for the error cluster (which they probably wouldn't anyway, since it has no meaningful automatic text description).

For what it's worth, I can say that in almost all my code today, subVIs have the terminal called "error in" and I haven't seen anyone complain that I haven't thought things through because of it.

[soupy]

I came to that conclusion from observing other developers (including myself). We tend to have this knee jerk reaction to larger block diagrams/front panels. If you show buffer allocations, you'll realize that graphical size does not correlate with performance (in-place structures takes up lots of visual room). 

In this case, you're talking about terminals on subVIs that will never be displayed to the user. I'd much rather have the extra 10 characters describing what is going on, than save a litle block diagram space. Here, no strings are being compared, so name length should not have an effect on performance. "annoying and unneeded" are are pretty weak argument against consistency.

I would argue against any time being saved by developers leaving out this text. If this text is left out, you'll want to open the VI and verify that some non-default value has not been set, as you can't determine whether the developer was using a default value, or forgot to program in good style. I'd say this actually takes more time. (of course, all the time this could potentially save us has been spent reading this thread...)