Can you measure good coding style?

[Jim Kring]

One pattern that I see in the LabVIEW code that I write, is that the more of a hurry I'm in, the less time I take to straighten my wires. The idea struck me that this might actually be a very useful metric for indicating areas of code that are in need of some clean-up. Of course, this metric would need to be normalized to the total number of nodes in a given diagram -- hence, the Wire Bend to Node Ratio. Ideally, this number would approach zero (no bends).

Along those lines there are other metrics that might be useful for measuring how well code conforms to style guidelines. For example, a node alignment metric might also be useful. A node could be considered "aligned" if one of its edges is aligned with the edge of another node. Nodes that were aligned with multiple nodes would be given more weight, on a per node basis.

These metrics are just a couple examples of ways to measure good coding style. Has anyone ever tried to measure these, or something similar? They can be easily automated using scripting and tools like VI Analyzer.

[crelf]

The VI Engineering VISTA program has a complexity tool embedded in our project management software, although I'm considering breaking it out and making it available as a separate tool integrated into the LabVIEW project explorer. It uses hueristic measurement of several code facets, including wire counts, nodes, and more. Watch this space for an update coming soon...

PS: If you're interested, I may be looking for some beta testers in the near future...

[Steve Mate]

I wonder if it would be possible to detect code that should be made into a subVI? Probably best left to the humans...code completed in a rush can be short on subVIs.

[Jeff Plotzke]

I wonder if it would be possible to detect code that should be made into a subVI? Probably best left to the humans...code completed in a rush can be short on subVIs.

It would be interesting if you could scan through the code and detect a "code sequence" that you use in multiple places -- something that could be made into a subVI...

[Grampa_of_Oliva_n_Eden]

It would be interesting if you could scan through the code and detect a "code sequence" that you use in multiple places -- something that could be made into a subVI...

.... So that would involve scanning through all of the branches of all of the widgets hanging from the BD reference and matchinging up identicle branches... hmmm... but when i create sub-VI I think about what they do when creating the names and icons. I could see the utility finding common code snippets and expecting me to name them! I do not know if that would be much fun.

Re: Jims Q

Well Darren has shown that you can quntify bad stuff. Would a neatly laid-out Rube Goldberg machine implemented in LV count as "Good Code"?

The only indicator I have found for good LV applications is the (brace yourself) aspect ratio of the VI Hierarchy screen. Somewhere around 3:4 seems to be a good balance between complexity of code and use of sub-VI's. I t seems the worst VI I have seem are either very flat (all code in top level, ussually the rsult of over-using wizards) or very deep, which are the result of very good ex-C developers.

Ben

[Rolf Kalbermatter]

.... So that would involve scanning through all of the branches of all of the widgets hanging from the BD reference and matchinging up identicle branches... hmmm... but when i create sub-VI I think about what they do when creating the names and icons. I could see the utility finding common code snippets and expecting me to name them! I do not know if that would be much fun.

Re: Jims Q

Well Darren has shown that you can quntify bad stuff. Would a neatly laid-out Rube Goldberg machine implemented in LV count as "Good Code"?

The only indicator I have found for good LV applications is the (brace yourself) aspect ratio of the VI Hierarchy screen. Somewhere around 3:4 seems to be a good balance between complexity of code and use of sub-VI's. I t seems the worst VI I have seem are either very flat (all code in top level, ussually the rsult of over-using wizards) or very deep, which are the result of very good ex-C developers.

This last comment depends a bit I think. Yes I'm a bit a seasoned C programmer (but learned most of what I know about C after I learned LabVIEW). Having learned programming in Pascal might also have helped my tendency to opt for more functions than less.

While applications tend to follow your screen hierarchy metrics somehow, that is not always the case with function libraries.

I would agree that sorting out every wishy-washy into its own subVI is not very helpful both for maintenance and understanding of the code (and creating the extra icon and connector pane also needs some time) but I would say it is better to have a subVI to much than one to little.

I really can't get happy when seeing someones code where:

1) a diagram that covers more than a screen size and is stuffed with all kind of code making it a major task to try to understand what the VI does.

2) or an application that has all over the place similar or the same code constructs implemented over and over again.

That said the programs where various VIs are plopped into the diagram where the wiring and connector pane make it obvious that the VI was created with "Create VI from selection" without further edits to that subVI can make me even more sick.

Or another bad design topic where many subVIs that all do more or less the same with slight differences are sprinkled through the entire application hierarchy.

Rolf Kalbermatter

[Jeff Plotzke]

Or another bad design topic where many subVIs that all do more or less the same with slight differences are sprinkled through the entire application hierarchy.

Now that's a coding challenge right there! Create a program that reads a subVI, understands what it does, and then detect other VIs which do similar functions! whew...

[robijn]

Now that's a coding challenge right there! Create a program that reads a subVI, understands what it does, and then detect other VIs which do similar functions! whew...

Sounds good ! We could give a collection of VIs to several people and let them judge the style quality factor. Then we feed the same VIs to te candidate programs and let them determine their style quality factor. The best approximation wins.

I'm a bit affraid of the centence "understands what it does" though. I don't have good experience with computers saying they understand me.

Joris

[Barrie]

This is terribly unscientific but I have found that a VI that doesn't draw right, doesn't run right. I have abandoned approaches just because it doesn't look right and its rarely failed me. Its an aesthetic or gestalt thing. A very simple example is that my VIs run best when the dataflow is left to right, top to bottom, like a well drawn schematic.

Call it, if you will, another example of "Thinking In G"

So, I guess the question is; can aesthetics be quantified? VI Analyzer is a good start, but perhaps what you are asking is verging on AI.

Please don't take this as discouragement, just a discussion point.

Cheers,

Barrie

[PaulG.]

This is terribly unscientific but I have found that a VI that doesn't draw right, doesn't run right ...

I tend to agree. I've spent literal weeks trying to debug a poorly drawn (not drawn by me, of course ) LV block diagram that I would have been better off just deleting entirely and starting from scratch.

[LAVA 1.0 Content]

Lost of good ideas in this thread on "how to measure coding style", but a bit too "human dependant"... I mean... In the end, who, better than a couple of experienced developpers to judge coding style ?

Without any pretention, I just throw a "keep it simple - keep it silly" idea : why not just doing "brutal statistics" on the whole hierachy using "Metrics:Advanced" (see screenshot). Defining an "indice"* with a statistic such as :

- number of controls/indicators per VI,

- number of globals/locals call per VI,

- percentage of VI reading/writing a global (=good or bad use of a global, IMO),....

list to be continued by people more experienced

Of course, nothing will replace human analysis, but IMO statistic is a very good way to perform a pre-selection coding style ; the indice would just say "novice style : should attend LV basic 1 training", "intermediate : should attend : Intermediate LV training", and so on...

* : not sure of that word : "indice"