Timeline for Perf wrapper for Excel VBA
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 22, 2017 at 17:55 | comment | added | Mathieu Guindon | @R3uK I mean you can wrap a global all you want, at the end of the day any code can use that global and bypass your wrapper ;-) | |
| Mar 22, 2017 at 17:46 | comment | added | Mathieu Guindon |
That said in other languages, a declaration is often an executable statement, so where it's at is of prime importance; in VBA/VB6, Dim isn't executable, so where it's at makes no difference as far as variable lifetime is concerned - so it's just a readability/maintainability thing.
|
|
| Mar 22, 2017 at 17:45 | comment | added | Mathieu Guindon | Oh, absolutely!! ...except if your boss is non-technical and the app is business-critical and you're just not authorized to check in non-functional changes that "don't bring any business value or fix any actual problem" =) | |
| Mar 22, 2017 at 17:44 | comment | added | Brandon Barney | @Mat'sMug taken to the extreme it makes perfect sense. Thankfully, I havent run into that issue before. I will admit that there are times where I have to scroll up repeatedly, but usually because I forgot to declare something. In the case of a 2000 line routine though, couldnt an argument be made for refactoring the routine into multiple subroutines? I am somewhat of a novice, but I would think that it would make the code somewhat easier to follow in some cases, and it would also potentially help with variable management. I could be dead wrong on this of course. | |
| Mar 22, 2017 at 17:39 | comment | added | Mathieu Guindon | @BrandonBarney take it to the extreme: an ugly 2000-liner procedure that has every variable declared right next to where it's used, vs the same ugly 2000-liner procedure that has every variable declared in, oh, a 2-screensfull wall of declarations at the top. With the latter (which I've worked with) you constantly find yourself scrolling up and down the procedure and lose where you were at, and waste considerable time doing just that, not to mention it's impossible to tell at a glance which variables are used and which are just dead code, at least without Rubberduck telling you. | |
| Mar 22, 2017 at 17:14 | comment | added | Brandon Barney | @Mat'sMug Out of curiosity, why should declarations be close to their use? I always thought it was opposite, but that may just be personal preference. I tend to declare whatever is easiest to use at the beginning, and then refactor for performance at the end. To this end, declaring them in a block at the top makes it much easier for me to see if I have gotten out of control and if I need to refactor. | |
| Mar 22, 2017 at 12:09 | vote | accept | R3uK | ||
| Mar 22, 2017 at 14:00 | |||||
| Mar 20, 2017 at 12:12 | comment | added | R3uK |
Thx for the valuable inputs! I didn't though of the object parameters when I wrote the base that I reused more recently for this one (as I only use this on main program called by buttons), but indeed it is a deal-breaker for more general use (and ParamArray is a pretty common coding method across languages) ! ToggleWaitMode procedure could be interesting with a few Public variables, but I'm pretty intrigued by the class approach, and wondering what do you mean by "leaky abstraction"?
|
|
| Mar 18, 2017 at 16:51 | comment | added | Mathieu Guindon | @Vogel612 yes, I is =) | |
| Mar 18, 2017 at 16:43 | comment | added | Vogel612 | you is working on Rubberduck? | |
| Mar 17, 2017 at 16:01 | history | answered | Mathieu Guindon | CC BY-SA 3.0 |