I'd love to see an option for the label of structures to be visible by default, similar to the already existing "Subdiagram labels visible by default" option.
We could certainly make the option. But why? Having them everywhere would be a lot of noise on most diagrams. I would think that would hurt readability. I certainly wouldn't want it to be enabled on most diagrams that I read -- and I do a lot more reading of other people's G code than I do writing my own G code.
What's the goal? Are the structure borders not distinctive enough?
Admittedly, I was thinking about case structures (most important) and loops, for which our internal style guide dictates to have the label visible.
For the case structures, the label will spell out the condition that feeds into it. The idea being that when I look at the code, I can read what kind of logic the case structure is actually handling.
For the loops, we make a rule of describing what the loop is iterating through.
Not sure about other structures, now that you question it... We don't have rules/guides for them.
Speaking as member of LV R&D: We could add the feature if enough folks felt it was valuable. It would be a low priority without overwhelming kudos.
Speaking only for myself as a G developer:
Whenever I hear about a new style guide requirement one of my customers uses, I ask myself whether my team should be adopting it for our G code. This is a new one, so I spent some time today going through a bunch of VIs. I looked at some of my personal and professional VIs. I also looked at some VIs from others that I'd never reviewed before to see if I thought labels would help me understand the contents.
I'll restrict my comments to case structures and loops since that's what you primarily label.
My conclusion: I would strongly question the value of that style guide requirement.
I see this requirement would proliferate useless noise all over the diagrams and waste a lot of dev time typing out the obvious, without adding anything to the understanding of the diagram for others.
First question: Do you put "Checks for error" every time you connect the error wire to a '?' terminal?
Loops: In the places where I needed to document the loop, the structure label would not suffice for space or readability (in my opinion).
Labeling an autoindexing For Loop is redundant -- I can see the terminal that is being autoindexed, and the nodes inside say what operation is being performed. If I cannot tell the operation from the nodes, then I need better icons or labels on the nodes... but a label on the loop doesn't help with that. Here's one I did not write... just glancing at it, I know that it is translating the input integers to their respective strings. I don't think a label helps me know that.
On case structures, I've got a few where the Array Size prim is wired to '?'. One frame is Default and the other is 0. Do I really need a comment that says "check for empty array"? I don't think that helps me or other devs.
Enum case structures are even more obvious... we are selecting from the states defined by the enum. I see that there are frequently comments inside the frames to explain the needs of each enum value, but labeling the case structure overall seems pretty redundant.
I did find some where a comment of some sort would help my comprehension, but I don't think the label was a good place -- they were usually places where I would need explanation of some tricky optimization, or a summary of all the the While Loop's stop conditions.
Overall, as G developer, I would not adopt that style requirement, and I would discourage anyone on my teams from following it. And, by implication, I would discourage LV R&D from spending time working on a feature to support that style.
If you find it valuable, don't stop. And I wouldn't stand in the way of R&D putting it in if lots of customers clamored for it.
Thank you for going out of your way, sharing your thoughts. It is always very interesting to hear your opinion.
Context
Let me start off by saying that the idea behind this style guide is not to explain the code itself (eg. "translate the input integers to their respective strings") but rather what this code does in the context (maybe something like "get names for all selected items" or similar).
Why? Many of our customers are not software developers by profession, but test engineers who have their field of expertise somewhere else and just need to use software. It is my experience of many years of customer project work that it helps them - and us - a lot if we try and give context as much as possible.
The Style Guide
I had another critical check of various VIs both written by ourselves and by our customers with your feedback in mind. I agree and admit that not each and every case/loop structure has a visible label, and doesn't have to. In the following example, neither the error structure nor the while loop nor the event structure would benefit from a visible label.
example of "no labels needed"
Loops
I realise now that I was wrong in extending our case structure label style guide to loops, let alone all structures! Enthusiasm while writing the idea post got the better of me. For any given loop, the subdiagram label is there to provide space for explanation (and we have the VI Analyzer tests to check those if we see the need for it). So I stand corrected and withdraw that part from my idea.
Examples
There are many places where I don't want to miss (i.e. do not allow to be missing) the label containing a bit of explanation:
- Not interested in the fact that the case structure represents values of an enum - we want to see that the case structure is separating between one group of values (single bit) and others (bytes etc.):
- Not interested in the fact that the I32 of the SubVI left to the case structure is wired to the case selector - we want to see that data manipulation is done according to the function code that the integer value (taken from the message) stands for.
- Not interested in what is wired to the case structures, but what decisions are made there.
My conclusion
I can totally see where you're coming from. I also realise now that I did not give enough context/explanation when posting the original idea, sorry for that. For us, pursuing this style (adding labels to case structures) has helped with readability, not taken away from it, and it made people write cleaner code because of having to think and spell out what they (and we) are doing.
We also enable the "Show created constant labels" option, which then are hidden again for maybe 20% of constants dropped because the label doesn't help - eg for error constants. Still, going this route, we end up with much more documented constants then the other way around. I would hope that enabling labels of case structures by default would work in a similar fashion for us.
Rephrased idea
I'd love to see an option for the label of case structures to be visible by default, similar to the already existing "Subdiagram labels visible by default" option.
PS: I know that Steen's team at GPower makes heavy use of this, too. Maybe he wants to add to this discussion?
For several years, I also used the label for case structures. I stopped doing it because I found a lot more value in putting in what decision was made in the subdiagram labels. For example, using your BIT image, I would not have the label, but in the subdiagram label would be something like "Addressing a single bit - apply offset". A side note on that image, you question is not correct: it implies a Boolean, not an Enum. The question should be something more like "What is the variable type?", and that just becomes obvious because of the label on the control being fed right into the case selector.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
That's exactly what I don't want, as this case separates between handling those types that are bit-based (at this point in time it's only one of all the types) and all the rest. I want the label to ask a question and the subdiagram label to answer it.
Edit: Fair enough, though, it might be better phrased as "One of the types addressing a single bit".
Again, I'm not saying this is the (only?) correct way to handle this. Hence my usage of the words I and want.
I want to reiterate that I agree that it's perfectly valid and possible to have the same information only inside the case structure, and that saves on screen estate by not having to make the label visible.
But what proved useful to us in our customer projects was to separate the information into two parts and have the first part (question) in the label of the case structure and the second part (answer) inside the case in the subdiagram label.
I don't do this as a requirement, but have used structure labels in the past. More so before the sub diagram labels where available.
If the option was there, I'd probably turn it off.
Still a +1. If this helps people to do better documentation (in their own way), it seems like a valid request.
I do wander... If this applies to case structures, shouldn't it apply to (conditional) disabled structures as well? Or maybe even all multiframe structures?
> We also enable the "Show created constant labels" option
I do use that one. Naked constants are really problematic. Especially useful when you start recognizing that two constants on different diagrams represent the same value and should be moved into a common subVI.
