Inquiry - What is your Modularity Index?

[Wiebe@CARYA]

The 3:4 hierarchy might not be achievable in all applications.

At the moment I'm working on an application with about 40 MMI's. They all
communicate with one hardware layer (through user events and buffers). This
will make the hierarchy very wide!

Getting a objective hierarchy is also difficult, if you start a lot of
dynamic code.

Regards,

Wiebe.

[Ben]

Weibe wrote;

The 3:4 hierarchy might not be achievable in all applications.

I agree!

I have another application that has 40+ dynamic plug-ins. The aspect ratio on that one is probably 1:20, but each plug-in by itself is still about 3:4. But again the aspect ratio tells a story in itself.

Q: Has anyone ever looked at one of those DSC Wizard generated app's? Depending on the complexity, I have seen those go to an aspect ratio of 1:50 with NO dynamics.

Ben

[PJS]

I found this pretty funny.... My MI goes between 2.2 and 4.7.  Depends on the size and complexity of the project.  Very simple programs obviously have a very low MI... the more complex, the higher the number... GEE imagine that... But what this tells me is that I do a darn good job of deciding WHEN to modularize.  Since version 4, I have been of the opinion if something needs to be done more than twice or may be applicable to different applications, it becomes a subVI.  I guess this has worked pretty well. 
IMHO evaluating software is a subjective thing.  Over years of doing this, I have found that good developers migrate towards the same things.
I have seen LabVIEW developers who have been at this longer than me, and their code just plain sux.  And others who have been at it a short time who have taught me a thing or two.  The biggest advice I could give on this to a beginning developer (especially one in a closed environment, meaning by themselves or maybe one other person isolated from other labview development people) would be to regularly monitor the forums and download samples often...  Many times, if someone posts bad code, comments and suggestions on improvement are made by the grey beards... I started out using info labview and developed some very good habits... It is probably the reason why so many grey beards are here on the forums... to help out the newbies. 
I guess what I am getting at here is regardless of your MI, what truly needs to be addressed is your software architecture, and not development of subvis for the sake of a higher MI.  This could lead to other worse things happening, like memory allocations being made unnecessarily.  some of my 'sub-vis' in my utility pallete are merge only... so it is maintained, yet the code is directly dropped in... however if a bug is found out, it becomes hard to track down everywhere it is used... Which is why most merges I do also drop a comment with the VI name in it, so if I need to find it later, I can search for the text string! 
OK, I am ranting and will stop... Have a great day, Paul has left the soap box

[Gabi1]

---

The 3:4 hierarchy might not be achievable in all applications.

---

That actually raise a naive question: i have applications with lots of vis called dynamically or only via reference. they do not show up in the hierarchy, and if the project explorer becomes too big, it is difficult to track them. anyway to make them show up in the hierarchy?

[Ben]

Gabi1 asked "...anyway to make them show up in the hierarchy?"

Sure!

Even before the Project was implemented Lv developers ahs that same challenge.

I insist all of our applications be developed using a "Tree.VI"

A Tree.VI is never intended to run. It is a VI that contains all top level and dynamic VI's used by the application. The Tree lets you load all VI's by openeing a single VI to satisfy the hierachy issue. It also serves as a sanity check to makes sure code changes do not break dynamicVI's. If the Tree is broken, you did something wrong. One of the most useful (IMO) aspects of the Tree is when you have widely used typedefs that need changed. If you have the tree open when the typedef changes, every one knows about it. Similarly if you want to rename a VI or save it to a new location. The Tree is alos handy if you are doing a "Source Distribution". Since the Tree has links to everything, the Source Distribution can pick-up all of the VI's that are used and create a fresh clean folder of all of the VI's propely linked and leave all of the junk files behind.

Trees are cool!

Ben

[Gabi1]

Thank you Ben.

i will make Tree.vi integral part of my projects!

[GuenterMueller]

I also maintain the "Tree VIs" mentioned by Ben. That makes live quite easy if you want to know that every VI is present on hard disk or if for any reason I want a recompile of the tree: Just open the tree and press Ctrl+Shift+Run Button.
I see MIs for my trees between 3.2 and 5.11. VIs in user.lib (I only tested a few) range from 1.35 to 20 in their MI. (Nevertheless I won't revise any of them.)
Have a great day, Guenter

[Neil.Pate]

Ah, that is what I love about this forum. Such great ideas freely volunteered.

I truely hope some day to be able to pass on wisdom like this.

<me> promises to himself to maintain a tree.vi for every project </me>

[Wiebe@CARYA]

I couldn't make anything decent without a tree.vi. Mine aren't actual trees,
I just put all my dynamic code in one vi.

The main reason I do this (next to noticing if you brake something) is that
you can search all your code. With 8.5 I belief you can search an entire
project, so this becomes less important.

Regards,

Wiebe.

[Gabi1]

Yes Wiebe, it already saves me quite a bit of time. trics like that makes it so much easier!

Thank you again Ben and the forum