Style in VBA.NET

[MikeJarosz]

I posted a similar memo on the Mrs. Peel thread that I would like to open to a wider discussion.

I have in the past worked in FORTRAN, Cobol, Basic, Unix, and a little bit of C, not to mention two assembly languages. In all of them, it was considered bad practice to put non executable statements or simple assignments inside of a loop. Example:


'area of a circle
For Radius = 1 to 1000
PI = 3.14159
Area = PI * Radius * Radius
debug.print Radius; tab; Area
next Radius

In the above code, PI is assigned 1000 times, when it only needs to be done once before starting the loop.

I've been learning the Revit API by dissecting the sample code provided by Autodesk. Almost every VB.NET example loops through the elements collection testing for certain conditions. When the condition is met, the code repeatedly does a DIM to explicitly create a new variable. Since this is in the elements collection loop, on a decent sized drawing, this could be thousands of cycles.

I mention this because I am assuming that the professional programmers at Autodesk know better than I about the inner workings of Revit API and MS VB.NET and the best way of doing things. Could it be that the Basic compiler is so much more sophisticated that the old rules of style don't matter anymore?

One other conflicting rule of scope was to DIM a variable as close to where it is first used instead of the top of the program, so the reader can easily locate the definition. Could this be what Autodesk programmers are doing?

I took the code for room data and rearranged it with the DIM statements outside of the loops. It worked OK and it seemed a bit faster. Will this make me look like a provincial peasant to the slick guys at the factory?

I just had one last thought. Maybe programming practices like this are why Revit can be so slow at times!

[GuyR]

Since this is in the elements collection loop, on a decent sized drawing, this could be thousands of cycles.

In this case PI is a constant and should be declared so.However for your in/out of scope local Element in the Revit command if you look at the IL you'll see some optimisation ;-) The bottom line is the CLR does a pretty good job of managing the heap and you won't normally need to worry about it.
As I've said before it's getting the current element in the loop that takes the vast majority of the time.


I mention this because I am assuming that the professional programmers at Autodesk know better than I about the inner workings of Revit API and MS VB.NET and the best way of doing things. Could it be that the Basic compiler is so much more sophisticated that the old rules of style don't matter anymore?
Most of the old rules are still valid. And being OO some new ones apply. In general define variables in/out of scope based on the overall application requirements and let the CLR take care of managing the memory.


One other conflicting rule of scope was to DIM a variable as close to where it is first used instead of the top of the program, so the reader can easily locate the definition. Could this be what Autodesk programmers are doing?
I think you're reading too much into this. In terms of optimisation I suspect they just haven't taken the time to try. And as I said in terms of potential performance gains this is way down the list. With modern IDE's and 'intellisense' finding definitions isn't an issue.


I just had one last thought. Maybe programming practices like this are why Revit can be so slow at times!
No that's not it. I would imagine with your large projects you are looking for methods to improve time to parse the element tree. For element instances if your code is doing a reasonable amount of work on each element and getting the user to select elements isn't an option then your best bet is multi-threaded walking the tree. Not simple ....

Guy

[clog boy]

The less code within a loop, the better. Assuming that it works and the results are correct. Try 'nesting' loops for example, on four or five levels, and then you learn to pre-define variables (at least in PHP).