Thank you for the evaluation. I incorporated almost all your changes. Your code looks quite different and for many that style is fine. I'll explain some of the style philosophy here, and deal with operational matters in the original thread http://www.vbaexpress.com/forum/showthread.php?t=2045
Note that this is a somewhat long routine. Call it "visually challenging." I took some liberties with stuffing content on lines to preserve visual context in viewing the code. For example, if I could go
if i=0 then exit sub
then that's a lot less distracting and makes the code easier to follow than
if i=0 then
exit sub
end if
which stretches out the code visually.
Some coders (and code prettifiers) would object to[VBA]if (long expression causing "then" clause to extend off the right side) then _
bVar = false : set foo=nothing : exit sub 'this line is actually singly indented[/VBA] preferring to add a line for end if. I only did this for single-line "then" clauses which are easy to visually process, while saving a line vertically.
Similarly, I used 2 or 3 lines to Dim instead of 9 or 10. Implicit variable typing is great for that, with the benefit that you don't see those irritating variable-typing ampersands in the revised code. (Yep - I initially slipped and used sResp$ when sResp is fine.)
There's a heck of a heck of a lot packed into this code, so it's both vertically and horizontally challenging. I compromised heavily to try and make it so you can follow it but not have it be 200 lines long! I grant that personal preference may vary here. I also grant the inherent cost of multipe statements on a line. But look at how many levels this code nests, and how long it is! (The obvious thought is to break out new routines. Unfortunately, for this application, it just makes you have to keep jumping back and forth to the subs, making it worse to follow the flow.)
Is this obsessively anal? Guilty. But taking all that trouble on the front end pays off a million-fold during maintenance and debugging, where sometimes 90% of code work is done. There's a huge While loop in that code, but for all this trouble, I can see all of it at full fontsize here in IE, and just about all of it in VBA IDE. (Signed, an incorrigible c coder
)
The static var. sResp$ declaration is shown as commented because this is for inclusion in normal.dot. I wasn't going to presume that my routine would be the first routine in anyone's normal.dot that has it.
The With Selection is a good coding practice and increases speed. It has drawbacks here, so I did not use it:
- Nested Withs are mondo confusing.
- Another indent level - more horizontal challenge.
- Its optimizing benefit is too minor to outweigh those.
The scope of that With forms another gigantic nesting level (68 lines), though that alone is not a dealkiller.
Anyway, style is a matter of style. I also believe in the statement "there's no accounting for taste," LOL. So YMMV.
[VBA] tagging on the board tag forces tab size 4 and makes other indenting decisions. [code] doesn't preserve whitespace accurately, and performs unnatural acts on indenting. Trust me, my code looks beautiful at home - argggh. Also, at home all the comments are aligned against the right edge of the screen, but neither of those tag features would process it accurately.
The guys that did the [tag] processors did a great job. I just wish there was one simply called [verbatim] that doesn't jack with anything, and w/ fixed font.
Reply With Quote
