I was always told that any time you can keep the main form code "light", and when certain functions may be reusable, it's best to throw them into a module, so that you can always just add the module to any other program as needed, rather than go back and rip the code from the form(s).
Maybe I was a little brief.. Your reason for using modules is for valid reasons of segregation and encapsulation. I said not to use modules more because they are static classes which tend to enforce procedural programming methodologies. Given that VBN is OO, and not procedural, deferring to modules is not encouraged. I do strongly recommend that form code be moved out to reusable components wherever possible. What I meant to say was "Dont make those reusable components out of modules[static classes], make them into proper classes instead, unless there really are no cases where one instance would be different to another or there is no case for multiple instances.
Code in forms should be solely involved with the donkeywork of creating the user experience rather than business logic.
For dimming vars in a procedure, I was told that it's best to always declare all of them at the top, so that they will be much easier to find should a problem arise, rather than having them scattered through, possible very large code blocks.
My 2 main objections to this are of dimming (reserving stach and possibly heap space for) many variables that will not be used because the method will return early, or somehow take a route through blocks of code that avoid them. The other is a reason that some have touched on; you may have a method that is 10 pages long. You shouldnt have a method this long, but suppose on page 7, you find the first use of variable X you dimmed at the top. What the heck is X? Scroll up 6 pages and find out..
Associated with this problem are the solutions/recommendations:
Name variables sensibly
Keep blocks of code short
Dont dim variables unnecessarily
Dim variables close to where they are used
Ensure variables die close to where they are dimmed
And I was also always told using "Call" before calling a function, also makes it easier to quickly understand code at a glance, because you can easily see that there is a call being made to a possibly oddly named function.
That may have been true in old vb6, which was a total mess and you had all these ways of calling a function:
FunctionWithoutArgs
Call FunctionWithoutArgs
result = FunctionWithoutArgs
FunctionWithArg "arg"
Call FunctionWithArg("arg")
result = FunctionWithArg("arg")
FunctionWithByValArg (byval) '
note the space between func and arg. intended
Call FunctionWithByValArg((byval), noByVal)
result = FunctionWithByValArg((byval), nobyval)
but not these:
Function()
Function(args, args)
Call Function()
result = Function args
Call Function args
What a mess! It still can be a mess now because syntax support for all the old variations was included. Suffice to say its easier to adopt one style of:
[result = ] Function()
[result = ] Function(args)
because at least VBN understands the syntax variations:
[Call|result=] Function[()|(args)]
Call is superfluous in all cases where it might be applied. A coding style from C# dictates:
If the object member starts with a capital letter, and has an opening ( after the name, it is a sub or function.
myObj.MySub()
result = myObj.MyFunc()
var = myObj.Property
Fortunately in VBN because of its tolerance to style, i can adopt this standard. I do not care to draw a distinction between a sub and a function -whose-return-val-im-not-using. Call can only be used in cases where the return value is not wanted, so to use it springs an inconsistency. Through all variations, the only consistent form is that as per C#, rule given above. I believe this consistency lends itself more to code readability than anything else. Other rules are:
Class names start with an uppercase
Object instances start with a lowercase letter
Constants are ALL_CAPS_AND_UNDERSCORES
MyClass.MyMethod() is a static call
myClass.MyMethod() is an instance call
MyClass.MyProperty is a static property etc
These can be followed in vb, though the visual designers have an annoying habit of capitalising every object instance: Button1 in VB, button1 in C#
And this has led to confusion with datasets, whose name is DataSet, and when dropped on a form, the intance is also called DataSet.
Such blurring of distinctions between class and instance automatically put VB programmers at an unfair disadvantage compared to other more strict languages. In programming in a more strict style, you can more easily break away from VB, should you get tired of the "it's not a serious language" stigma it has unreasonably attracted over the years; other languages will not seem so "hard" because the compiler is "overly critical", and (imho of course) it improves the quality of work
