To avoid having unnecessary code in my program, I am wondering which choice should I use:
Use the statement like this Imports System.Threading and then use the code Dim myTimer As Timer
Do not use the statement Imports System.Threading at all, but use a full declaration like this: Dim myTimer As System.Threading.Timer
Both choices give the desired result, but I want to avoid adding all extra code from System.Threading that I do not need.
The question came to my mind when I saw the answer to the question here: How to correctly terminate an application?
Here the user wrote …Threading.Timer(…, but didn't use Threading on the Timeout.Infinite.
Since I am using System.Threading in only one point in my code, which choice would be better?
Thank you.
You don't "add all extra code from System.Threading" if you use Imports. You just tell the compiler that you want to use that namespace, so you avoid always using the fully qualified namespace.
As a rule of thumb: use Imports whenever you need it at least once. Fully qualified namespaces don't make your code more readable, it's also harder to see what you use in this class if you omit the Imports.
You can use Code Cleanup On Save to ensure that unused Imports are removed from your code when you save the file. But again, this is just removing redundant code, it will not improve performance or whatever.
Another option (that I favour) is to use Add Reference and/or Import Namespace on the project's References tab rather than use Imports or fully-qualified names. Unless it's just a single instance or two, in which case I'll fully-qualify to tell me that I don't use this reference/namespace a lot in my code. It's just a preference. (Or should I say a "reference preference"? Perhaps not.)
Related
So, I'm writing a small program in VB.net and I was wandering if there's a replacement for the include statement I'm used to in C/C++? That's instead of making all my classes and functions "public shared".
Are their security concerns, or is it bad practice to keep declaring all the classes or functions I wish to use in other .vb files as public shared?
For example let's say I write a hashing function for passwords within passwords.vb and I want to use it within a UI file login.vb, to do this I would declare my hashing function as a public shared funtion within a public class (unless I'm missing another way). That way I can access it by using something along the lines of password.Hash(STRING) where password. is a reference to my password.vb file.
Now in C/C++ I would add an include statement to the header file that would define everything I needed it too. I know header files don't exist but there's not other way to include a separate .vb file, other than making everything public? It just seems odd to me and it feels like having possibly hundreds of public classes/variables/functions etc... is somehow the wrong way to do it?
I'm aware of .dll referencing as an alternative, but I don't really want to have 20 .dll files associated with a program if I can help it, or unless it should be like that?
Thanks for your help and I hope that what I'm asking makes sense.
Well you need to do some extra effort if you wish this separation.
Namespaces are not really enforced inside VB.net, but you could use them to arrange your code in such a way that you can use the Imports Namespace statement.
Lets say we have this dummy class, this would now be publicly accessible in your code without any extra effort
Module PasswordHandler
Public Function Hash(ByVal password As String) As String
Return password
End Function
End Module
However, you can change the namespace of the Module if you want to
Namespace Security
Module PasswordHandler
Public Function Hash(ByVal password As String) As String
Return password
End Function
End Module
End Namespace
And this would now "hide" the Module from your program, until you use the Imports ProgramName.Security statement on the top of your code, as the following:
Imports IncludeSampleVB.Security
Module Module1
Sub Main()
Dim salt As String = PasswordHandler.Hash("dummy")
End Sub
End Module
This way you could structure your code in a way that might seem more familiar to you :) Btw, for static functions, you can also simply use Modules, they don't have to be shared classes, as you could see here: Classes vs. Modules in VB.NET
It took me a while to even understand the problem I'm about to describe, so please let me know if the description is confusing...
I have an object called "cProp" that defines a number of sub-classes. To refer to these classes in other files in the project, I have to do something like...
Dim cp = New cProp.InflationRow()
I understand why this is; since the InflationRow is "inside" the cProp, I need to tell it where to find it. Fine.
But this, of course, gets tedious, so sometimes you want to fix it...
Imports cProp
Why doesn't that work? Why do I have to...
Imports ProjectName.cProp
You might wonder why I care, but these files are used in numerous projects with different names. So if I use Imports I have to change the project name in a bunch of places. I am aware that Namespace is likely the solution I want, right?
My confusion stems from the fact that the compiler can figure out just fine which cProp (which is the only one) I'm referring to in the code, so why not in the Imports? I think I'm missing something fundamental here.
It's because your project has a root namespace - you can see this in your project properties. You can delete this in the project properties - this will result in allowing you to simply use the class name from another project. However, namespaces are a good way to organize your classes. In VB, the project defaults to having a root namespace, which you don't see in your code files.
Within your project, since it seems to be all within the same root namespace, you don't have to qualify with the root namespace for code within the root namespace. The "Imports" statements are not within a namespace (only types can be within namespaces) - that's why you have to provide the full qualification there.
I have two following rows of code:
Microsoft.VisualBasic.Interaction.Beep()
or
Microsoft.VisualBasic.Beep()
The result is the same in this two rows.
what is Interaction class?And when shold i use it?
Thank you in advance.
Those two lines result in exactly the same code being generated. Which one you choose is a matter of style. Personally I would choose to simply use the Beep() command in the abscence of a namespace qualifier
Sub Main()
Beep()
End Sub
Between the two choices you presented though I would choose Microsoft.VisualBasic.Interaction.Beep() over Microsoft.VisualBasic.Beep(). The former is the fully qualified name of the method and it's completely unambiguous to the reader. The latter though is using a trick of VB.Net name resolution and one that would likely fool even the experienced VB.Net user.
One of the best things I love about Visual Basic is that it makes the code easier and usually contains shortcuts to functions commonly used, such as MsgBox, Stop and Beep. That's why both lines yield the same result, because they are actually the same.
Also, as #JaredPar mentions, is better to either use fully qualified name Microsoft.VisualBasic.Interaction.Beep() or just Beep() this will make the code more readable.
It is a bit of an odd-duck name and have no good guess beyond the methods being available in the Immediate window. The key is that the class is decorated with the <StandardModule> attribute. Which is a hint to the compiler to move the members of class into the global name space. So you can simply write MsgBox() and not bother with the class name.
Just like you could in VB6.
I'm currently trying to create a NEWID() function in my DataContext in LINQ using the solution here, however, when adding the partial class to my DataContext.vb or a separate DataContextPartial.vb, I get the error System.Data.Function is not available in this context because it is 'Friend'.
I've come across this when accessing data types before and that was in easy fix of setting it to Public, but I'm not sure where the properties for function could be or how to change them.
The code I have is converted to VB.NET from the C# in the linked answer above:
Partial Public Class CMSModelDataContext
<[Function](Name:="NEWID", IsComposable:=True)> _
Public Function Random() As Guid
Throw New NotImplementedException()
End Function
End Class
Thanks for any help in advance.
I can't remember offhand whether VB applies the "Attribute" suffix automatically. Try this instead:
<FunctionAttribute(Name:="NEWID", IsComposable:=True)>
... and make sure you have an import for System.Data.Linq.Mapping.
EDIT: It looks like VB does apply the Attribute suffix, so I suspect you were missing an import or a reference. However, specifying FunctionAttribute explicitly will at least help you to verify this by removing the "false positive" of System.Data.Function.
I believe you should
Import System.Data.Linq.Mapping
because FunctionAttribute resides there.
You didn't import the namespace, and compiler went to look for the class in the wrong direction. Trying its best and seeing that you have imported System.Data, compiler assumed you want to use System.Data.Function which is an internal (Friend) class in System.Data.dll assembly, hence the error.
One can wonder what exactly is the purpose of this error message. If the class isn't accessible anyway, why even bothering to tell about it? I think the reason is you could've referenced your own assembly forgetting to make some of types Public. It makes sense that compiler warns you that it sees the class but you just can't use it. It also makes sense applying same rules to all references, including framework libraries, although obviously you can't modify anything in there.
I would argue that FunctionAttribute is not a particularly good choice of name because it's begging for wrong namespace imports and related confusion.
I have a Util module in my VB.NET program that has project-wide methods such as logging and property parsing. The general practice where I work seems to be to call these methods directly without prefixing them with Util. When I was new to VB, it took me a while to figure out where these methods/functions were coming from. As I use my own Util methods now, I can't help thinking that it's a lot clearer and more understandable to add Util. before each method call (you know immediately that it's user-defined but not within the current class, and where to find it), and is hardly even longer. What's the general practice when calling procedures/functions of VB modules? Should we prefix them with the module name or not?
Intellisense (and "Goto Definition") should make it trivial to find where things are located, but I always preface the calls with a better namespace, just for clarity of reading. Then it's clear that it's a custom function, and not something built in or local to the class you're working with.
Maybe there's a subtle difference I'm missing, but I tend to use shared classes instead of modules for any code that's common and self-contained - it just seems easier to keep track of for me, and it would also enforce your rule of prefacing it, since you can't just call it from everywhere without giving a namespace to call it from.
I usually put the complete namespace for a shared function, for readibility.
Call MyNameSpace.Utils.MySharedFunction()
Util is such a generic name.
Example from the .Net framework. You have System.Web.HttpUtility.UrlEncode(...). Usually you refer to this as HttpUtility.UrlEncode since you have an import statement at the top.
The name of the class which has the static utility methods should be readable and explainable. That is good practice. If you have good class names they might just as well reside in a Utils namespace, but the class name should not be Utils.
Put all your logging in a Logger class. All your string handing in a StringUtils class etc. And try to keep the class names as specific as possible, and I'd rather have more classes with fewer functions than the other way around.