VB6 Feature not included in .NET

  • Thread starter Thread starter Luke R
  • Start date Start date
L

Luke R

One thing i used to use alot in vb6 was that tiny little button in the
bottom left of the code window which allowed you to view either the whole
code file, or just the function/sub you are currenly in.

This was awesome when dealing with big functions inside big code files. You
could page up and down without accidentally entering the next/previous
function. Then they got rid of it in .NET and now we have this treeview
style collapsable thing which just doesnt cut it.

I suggest they bring it back. It was a really useful feature.
 
Luke R said:
One thing i used to use alot in vb6 was that tiny little button in
the bottom left of the code window which allowed you to view either
the whole code file, or just the function/sub you are currenly in.

This was awesome when dealing with big functions inside big code
files. You could page up and down without accidentally entering the
next/previous function. Then they got rid of it in .NET and now we
have this treeview style collapsable thing which just doesnt cut it.

I suggest they bring it back. It was a really useful feature.
Click to expand...

http://connect.microsoft.com/VisualStudio/Feedback


Armin
 
I was curious what the old VB6 expert would write, however a typical
(correct) Armin answer

Cor
 
One thing i used to use alot in vb6 was that tiny little button in the
bottom left of the code window which allowed you to view either the whole
code file, or just the function/sub you are currenly in.

This was awesome when dealing with big functions inside big code files. You
could page up and down without accidentally entering the next/previous
function. Then they got rid of it in .NET and now we have this treeview
style collapsable thing which just doesnt cut it.

I suggest they bring it back. It was a really useful feature.
Click to expand...

If some of your functions are so big that you need to use
PageUp/PageDown to browse through them, I think you have
bigger problems than missing this feature :)

I say: Good riddance to this feature.

Sorry. Don't mean to be rude, but I strongly feel that this
feature is superfluous if one follows standard best practices
and keep cyclomatic complexity down in all methods and
functions. Anything that encourages the developer to move
away from the old stream-of-thought approach to writing
functions is welcome.

Regards,

Joergen Bech
 
I dont understand... the only way that this feature would not be convenient
is if you only had a very small number of functions within a physical file.
When dealing with large projects, is it a best practice to spread your
functions over a large number of files, even if you have alot of functions
that are very similar?
 
What I am saying is that it is a best practice to keep functions and
methods as short as possible/appropriate. Typically, if a function
extends over more than 10-30 lines, it is probably doing too much
work and could be broken down into smaller, more readable chunks.
Even within a single unit of work, there might be complex conditions
that could be turned into a single verb to improve readability.

As such, you would never need to use PageUp/PageDown to
browse a single function as any function would always fit in its
entirety on the screen - at least vertically.

Of course, there are a few exceptions where one could still be
forgiven for writing longer functions.

In my current project, I have yet to write a single class bigger than
a couple of thousand lines. I usually split classes of such magnitude
into partial classes in order to organize the code into manageable
chunks. I am not a great fan of regions. I prefer having all my code
expanded at all times.

Also: One or more files per class. Never multiple classes per file,
even though this is possible in VB.Net (but was not the case in VB6).

When you ask about spreading functions over a large number of
files, even though a lot of functions are very similar, it sounds to
me like you are still thinking about the copy/paste approach to
coding one was prone to do in VB6 which - though it supported
encapsulation - did not support inheritance.

I used to think I would never need inheritance for much - if anything.
Now, I use inheritance all the time and do not have a lot of functions
that are very similar, as you put it.

/Joergen Bech
 
Yeah but sometimes you need to have big functions. Sometimes the amount of
data you have to pass back and fourth between functions ends up making your
process more complicated than what it would have been if you had just kept
it all in one or two functions. I find that a well commented and laid out
large function is easier to work with than lots of small functions. I only
use smaller sub functions when i need to do a repetitive task, or to get
information stored in arrays/dataset/lists and i dont have any problem with
complexity.

When i say similar functions, i mean similar categories. If i split my code
files into categories, i would still have a large number of functions in
each category. Inheritance is of no use when you require lots of functions
that may be similar but have important differences which can not be combined
and can not be used as templates for similiar functions
 
Luke R said:
Yeah but sometimes you need to have big functions. Sometimes the amount of
data you have to pass back and fourth between functions ends up making
your process more complicated than what it would have been if you had just
kept it all in one or two functions. I find that a well commented and laid
out large function is easier to work with than lots of small functions. I
only use smaller sub functions when i need to do a repetitive task, or to
get information stored in arrays/dataset/lists and i dont have any problem
with complexity.

When i say similar functions, i mean similar categories. If i split my
code files into categories, i would still have a large number of functions
in each category. Inheritance is of no use when you require lots of
functions that may be similar but have important differences which can not
be combined and can not be used as templates for similiar functions
Click to expand...

I don't want to harm you, but this is more traditional and procedual
thinking like it is used in VB6. It is not OO thinking.

With OO you also shouldn't have 'similar functions' since you would try to
make more generic methods.

Greetings,
Robert
 
Yeah but sometimes you need to have big functions. Sometimes the amount of
data you have to pass back and fourth between functions ends up making your
process more complicated than what it would have been if you had just kept
it all in one or two functions. I find that a well commented and laid out
large function is easier to work with than lots of small functions. I only
use smaller sub functions when i need to do a repetitive task, or to get
information stored in arrays/dataset/lists and i dont have any problem with
complexity.

When i say similar functions, i mean similar categories. If i split my code
files into categories, i would still have a large number of functions in
each category. Inheritance is of no use when you require lots of functions
that may be similar but have important differences which can not be combined
and can not be used as templates for similiar functions
Click to expand...

If your subfunctions access private or protected member data, you do
not have to pass them from the flow controller to the subfunctions
that do the grunt work.

If you have to pass a large number of parameters between classes,
you probably need to group and wrap them in classes and just pass
a few objects by reference. If you feel you have to pass a dozen
variables to another function to get some work done, you should
probably start out refactoring your data structures/classes before
you think about refactoring the code that operates on them.

The problem with a "well commented and laid out large function"
is that you have to read through the whole thing to get an idea of
what tasks it performs.

The best analogy I can think of is a book without a table of contents.
Fine, if you have been told that this is a great book and you should
just read it once, cover to cover. Not so great if you are standing in
a bookstore and want to get an idea of what it is all about.

Regards,

Joergen Bech
 
Hi,

In my idea is this a very strange discussion.

Luke is asking if there is in an anology with a car an open roof on VBNet.
Than Armin shows a page where you can give that as suggestion. Others are
telling why you don't need an open roof.

If I like an open roof, than it is my own favorite and nobody can tells me
not to use it.

Cor
 
Cor Ligthert said:
Hi,

In my idea is this a very strange discussion.

Luke is asking if there is in an anology with a car an open roof on
VBNet. Than Armin shows a page where you can give that as
suggestion. Others are telling why you don't need an open roof.

If I like an open roof, than it is my own favorite and nobody can
tells me not to use it.
Click to expand...


Hi Cor,

my 2c to this topic:
I think that debugging is sometimes easier having one big procedure
instead of many small ones: I once had to debug code not written by myself
and I was always jumping forth and back through often very small
procedures. This was more confusing than clarifying. If he had put it all
into a big procedure, the execution flow would have been more
obvious. As long as the code does not have to be reused, and as long as
there are not too many different tasks with a bunch of local variables
within the same procedure, I don't see why big procedures are a no-go.
I must admit that I was smiling as I read that Joergen considers >30 lines
being big procedures. I would probably have said >500 lines. At least as we
don't have nested procedures that I know from Pascal some years ago.


Armin
 
Yes, if he had just asked "where is this feature?", the discussion
could have ended there, but he gave his reason for wanting it, and
that gave me - and others - the impression that his coding style had
not moved with the times, which warranted an entirely different
discussion.

Sure, if you like coding that way and you are only coding for
yourself,
by all means continue writing code with methods that extend
over pages and pages, but if you are doing it on somebody
else's time and dime, eventually someone else is going to be
maintaining the code or participating in its further development
and the first thing that is likely to happen to such a code base
is heavy refactoring or even replacement.

I, myself, have been guilty of writing code that way in the past.
Stable? Yes! Commercially successful? Yes! Maintanable?
Not as much as I would have liked.

Not having seen any of the original poster's code, I can only
make general comments, but that does not make the discussion
less valid.

If one is requesting a feature, one should be able to justify the
inclusion of such a feature, and one should be prepared to
discuss the justification of the feature.

Regards,

Joergen Bech



Hi,

In my idea is this a very strange discussion.

Luke is asking if there is in an anology with a car an open roof on VBNet.
Than Armin shows a page where you can give that as suggestion. Others are
telling why you don't need an open roof.

If I like an open roof, than it is my own favorite and nobody can tells me
not to use it.

Cor
Click to expand...
---snip---
 
Joergen,

I go unwanted in this discussion. For me there is no law which says you
should not use more than 30 lines in a method. If it is by instance a
difficult Tax method but very procuderal, than I don't see why to split it
up in more methods only for this procedure. In my idea does it makes the
procedure less readable and with that less maintanable. I hate this kind of
programs as I show bellow.

Public sub CalculateMyTripToDanmark()
Destination(ThisTrip)
etc
..
Public sub Destination(byval ThisTrip as TripClass)
destination = txt.Destination
End sub

Taking the best approach in the right time thinking about others who have to
read it afterwards is for me the measure item .

Cor
 
Armin,

Sorry there is something missing in this message, I wanted to write that
your response was right to the point.

However I wrote already that you gave in my idea the correct answer.

Cor
 
I know what you mean. I was used to reading programs that
way and like you, preferred programs where I, step for step,
could see how things were done by scrolling through a big
method rather than jumping back and forth between tiny
fragments. I once downloaded the source for an early version
of Paint .Net and that program would appear to be nothing
but interfaces, abstract classes, etc. and I would go "where
is anything ACTUALLY being done?!?".

But: In the interest of extending or remodelling a program,
I can (now) see why it can be necessary to break up functions
into smaller units, each of which performs one taks and one
task only.

The "10-30" lines comment is, of course, not a hard and fast rule.
In my own work I have plenty of functions that are larger, but
I'll just as often write a function in order to replace a complex
single-line expression with a verb somewhere else.

Whether one approach is more readable than the other can be
highly dependent on how well subtasks are named or how
well a large function is commented.

You might find this article interesting:
http://www.doitwith.net/PermaLink.aspx?guid=39a0e537-5d0e-4f9b-ac5c-51e8b3d1d4ec

Your initial reaction to running this tool on a project and seeing
some if the greater values is likely to be "yeah, but it depends",
but in general, there is a reason why this tool and all other code
metrics tools come with a table which roughly categorizes your
functions in anything between "simple" and "unmaintanable".

I have used it frequently and like the "Maintenance Complexity"
as opposed by the more common, but much simpler, "Cyclomatic
Complexity" metric.

And no, I have not completely replaced common sense with a
collection of tools.

Regards,

Joergen Bech
 
Cor Ligthert said:
Armin,

Sorry there is something missing in this message, I wanted to write
that your response was right to the point.

However I wrote already that you gave in my idea the correct answer.
Click to expand...

No problem, I understood you correctly.


Armin
 
Does anyone know Steve McConnell's 'Code Complete'? There you can read why a
method shouldn't be to long and other things of course. It is all explained
very detailed. This book comes with more than 1000 pages but it's really
worth to read it. I can recommend it to all coders, independently of the
used language.

http://cc2e.com/



Robert
 
Everybody knows Code Complete :) And everything else on this
list should be considered required reading:
http://www.joelonsoftware.com/navLinks/fog0000000262.html

Yeah yeah, I only have the first edition, but I'm old.

....

But in related news, I came across this post:
http://blogs.msdn.com/fxcop/archive/2007/02/28/announcing-visual-studio-code-metrics.aspx

Nice to see that code metrics functionality is going to be included in
the box. This will make it easier for the manager to detect that young
rogue programmer sitting in a corner, checking in monstrous functions
and act upon it. And once he starts looking closer, who knows what
he is going to find, so better not show up on the radar:
http://meet-joe-bloggs.blogspot.com/2006/02/episode-6-code-review.html

Regards,

Joergen Bech
 
Joergen Bech @ post1.tele.dk> said:
If some of your functions are so big that you need to use
PageUp/PageDown to browse through them, I think you have
bigger problems than missing this feature :)

I say: Good riddance to this feature.

Sorry. Don't mean to be rude, but I strongly feel that this
feature is superfluous if one follows standard best practices
and keep cyclomatic complexity down in all methods and
functions. Anything that encourages the developer to move
away from the old stream-of-thought approach to writing
functions is welcome.
Click to expand...

I have to disagree. When editing function A some people only want to see
function A but not functions B and C. Especially with Class Explorer being
present, the feature definitely makes sense because one can see the class'
structure in class explorer and edit the class on a per-member basis.
 
Back
Top