>This sounds like a positively cryptic way to structure a VI. Not necessarily.
>What is good about a BD or FP that is pretty or clean or sterile, >if it communicates nothing about its function? Well what it does communicate is a structured and designed approach, and my argument would be that a simple diagram will always communicate it's function. (See my comments below). I would argue that having a non-sterile BD doesn't necessarily include the case that it communicates the VI's function! You could also argue that you can always work out what's going on, but taking the time to work out what's going on is exactly the reason to make it sterile and easy to read - to reduce this time. >And further, can such a VI be composed that doesn't require a large >recomposition to clean it up to this state? Mostly, I never get >to do anything over. So it is all experimental. Then when it works I >don't have the luxury of rewriting it for aesthetic reasons. Because LV >is self-documenting to a great degree if you habituate yourself to a >few things, like naming states and sub-vis cogently, why would I want >to make that stuff any harder to get to? > >I am actually offended by the ideas of a sterile top level. Hmm. I guess this probably comes back to software development origins or development constraints. In programming for whatever the reason (time/money/research based/experience), the development process is predominantly incremental and when you arrive at the end point you're done. A structured approach is only possible with some sort of planning and some sort of requirements before the development begins. Often this is not possible (as well I know;-), but even the most rudimentary "unspecified" project can benefit from planning. And incremental doesn't mean that it has to end up non-sterile. The primary benefits here are maintainability and extendability. Neither of these are requirements in a project that only has one goal; eg a research based or sole functional target, where it is never going to be maintained or enhanced. However if the complexity grows and grows, one day you will find yourself restarting from NULL because you cannot possible add that one last feature a client has requested. <This usually occurs at 2am with a deadline fast approaching> Having developed in the non-sterile way and the sterile way I would prefer sterility ;-) As my wife once said having looked over my shoulder, "How boring, all your code looks the same." I was pleased but I think she meant to it as a jibe! In our company, it is no longer acceptable to program in such an ad hoc fashion. Not because this doesn't achive results, but because the additional benefits of the a structured design are that (1) all members of the development team know where everything is located in any project (2) there is decreased learning time on software when the structure follows one of a pre-selected set of design patterns. These lead directly to a decreased development cost. cheers, Alex.
