vb6 used to support both procedure view and full module view. VB.net seems only to support the latter. Why would they do this? Is it perhaps because people generally have bigger screens now (and less need to scroll). I find that I have to scroll down a sub/function very slowly with full module view or else i'll inadvertently end up in a different sub. Is there a plug-in or another way to recreate procedure view?
+3
A:
Does this combo box do what you're looking for?
I also like this feature for condensing your functions in the IDE:
JohnB
2010-06-21 22:06:27
The collapse to definitions looks promising. It doesn't stop you scrolling beyond the end of the sub but at least it's pretty clear when you've gone too far. I'll need to play arounfd with it for awhile. It might be what I'm looking for. Thanks
kjack
2010-06-21 22:30:05
I still wish they'd left in the 'procedure view' option though..
kjack
2010-06-22 12:50:45
+2
A:
JohnB's answer has the gist of it - there's a bar at the top that will let you jump to a method. I wanted to add a note that you can also right-click on most any method name and chose "Go To Definition" to jump right to the the code for that method.
Joel Coehoorn
2010-06-21 22:24:18
In vb6 I'm generally in procedure view and use the equivalent of the bar to you mention to move from one sub to another.What I miss about procedure view is that you can't scroll beyond the end of a sub. I find this disconcerting in vb.net but maybe it's just something I need to get used to. Maybe my subs are too long..
kjack
2010-06-21 22:37:29
@kjack - VB.Net has a different approach to certain things, such that it should change the kind of code that you write. For example, you really shouldn't let your method lengths get much longer than a single screen or you could start running into variable lifetime issues with the garbage collector. In other words, if you need to scroll _within_ a method that much or can't just eyeball where the next method starts, you're doing it wrong.
Joel Coehoorn
2010-06-21 22:45:42
+1 for mentioning "Go To Definition." It's only of my favorite features! There's also "Find All References," but we could go on and on about Visual Studio features. @kjack: try using "Collapse to Definitions" in conjunction with the combo box to jump to a method and improve readability of that one method. A sub can never be too long in my opinion. (food metaphor, just want to be clear on that)
JohnB
2010-06-21 22:47:48
@Joel: I never took variable lifetime issues into consideration! Is there a good post on this? I will definitely write smaller methods from now on! (it's not hard to do anyway)
JohnB
2010-06-21 22:57:38
@JoelCoohoornYes my subs tend to be too long, I'm working on it :)(One thing that comforts me is in Code Complete where it reported that longer subs tend to have fewer errors!)@JohnB Big Macs rule. Way too much salt in subs.
kjack
2010-06-21 23:02:10
CodeRush has a feature called "Extract Method" that allows you to create a new method from a selected code block with a couple mouse clicks. The free version (CodeRush Xoress) only works with VS2008 though: http://community.devexpress.com/blogs/markmiller/archive/2009/06/25/coderush-xpress-for-c-and-visual-basic-2008.aspx
JohnB
2010-06-21 23:05:42
I find small subs harder to name than big ones. I think what I need to adopt is a naming convention that gives a hierarchial ranking of subs. Writing more subs makes for a long list to choose from the names of may not be that meaningful a year hence. (I think it's harder to name a small sub than a big one)
kjack
2010-06-21 23:09:54
@kjack: Sorry, no McD's for me. Good point on Code Complete, however, they also recommend declaring variables as close to the line of code that they are needed instead of declaring all variables at the top of the function. This technique improves readability and it makes it obvious where you should break chunks out into separate functions (I forget which page).
JohnB
2010-06-21 23:11:21
@JohnB -it's more that because VB6 used modules rather than true objects it tended to lend itself to long procedures. Thankfully I came to the language late enough that my role was more often updating old vb6 code, but I saw a lot of methods that pushed 10 printed pages or more (a nasty 46-pager still gives me nightmares). When you do that in .Net, you're gonna run into occasional situations where method variables survive a gen0 or even a gen1 collection; your program performance can suffer as a result. This was poor practice in vb6, too, but for some reason there was a lot of it anyway.
Joel Coehoorn
2010-06-21 23:44:21
I'm not sure why a long method is a poor idea just because .Net handles it poorly. However I'm not a fan of run-on procedures in any language, mostly from a readability point of view. Does busting up a 10-page method into 30 shorter procedures actually help performance though?
Bob Riemersma
2010-06-22 02:09:09
@Bob - Of course. Note the last sentence of my prior comment - it was poor practice in vb6, too, but developers decided to "get away with it" a lot more often back then. In .Net, _depending on what you're doing,_ "busting up" a very long method can indeed bring performance benefits.
Joel Coehoorn
2010-06-22 20:55:06