All geek questions in one place

Is it good practice to call module functions directly in VB.NET?

I have a module Utilin my VB.NET program that has methods common to the entire project, such as logging and property analysis. The general practice that I work in is to directly call these methods, not prefix them with Util. When I was new to VB, it took me a while to figure out where these methods / functions came from. Since now I use my own methods Util, I cannot help but think that it’s much easier and more understandable to add a Util.method before each call (you immediately know that it is defined by the user, but not in the current class, and where to find it), and hardly even longer. What is the common practice when calling procedures / functions of VB modules? Should we prefix their module name or not?

+3
source share
3 answers

Intellisense (and the "Goto definition") should make it trivial to find where things are, but I always preface the calls with a better namespace, just for clarity of reading. Then it’s clear that this is a user-defined function, not something built-in or local to the class you are working with.

Maybe there is a slight difference that I overlook, but I prefer to use common classes instead of modules for any common and standalone code - it just makes it easier for me to keep track of it, and it will also enforce your rule preceding it, since you can't just call him everywhere, not giving him a namespace.

+2
source

I usually put the full namespace for a generic function to read.

Call MyNameSpace.Utils.MySharedFunction()
+1

Util - .

.Net framework. System.Web.HttpUtility.UrlEncode(...). HttpUtility.UrlEncode, .

, , . . , Utils, Utils.

Logger. StringUtils .. , , .

+1

Source: https://habr.com/ru/post/1743367/

More articles:


All Articles