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?
views:
185answers:
3
+2
A:
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.
rwmnau
2010-04-29 14:41:40
You need modules for Extension Methods, but other than that I avoid them and use Shared Classes.
ho1
2010-04-29 14:49:30
"Goto Definition", no doubt about it. It is this trivial functionality which allows us to use Imports statements and call Module methods with the guarantee that we won't have to think twice about a method's origin. +1.
M.A. Hanin
2010-04-30 03:37:59
+1
A:
I usually put the complete namespace for a shared function, for readibility.
Call MyNameSpace.Utils.MySharedFunction()
Felipe Fiali
2010-04-29 14:45:37
+1
A:
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.
Mikael Svenson
2010-04-29 14:46:42
Agree, but this is a very small, temporary project with just very few methods in the Util class and this is how they want it implemented. For anything slightly larger or more long-term we would definitely modularize it a lot further
froadie
2010-04-29 14:49:03
I would still rename the Utils class to what it actually is utilities for. And if it's two things, go with two classes, even if it's small. At some place in time someone will add a function, and stick it in Utils, and it will grow and grow and grow :) The big Q is, should we allow ourselves to skip best practice when it's only a small temp thing? I'd say yes if the code is deleted in a little while and never ever touched again. But how easy is it to know this today?
Mikael Svenson
2010-04-29 14:53:41