Opinions on naming conventions

[agibsonsw]

Hello.

I'm very interested to hear peoples opinions on naming conventions in general, although I'm using VB.Net in particular currently.

Naming conventions are falling out of favour, I believe. Mainly because modern editors provide so much help - tooltips, intellisense - and it's easy to jump to a definition, etc.. "Context" and namespaces also reduce the need for detailed prefixes.

Personally, I will continue to prefix variables; perhaps because it's second-nature to me. I did start to prefer 's' (rather than 'str') for a string, etc., but I don't like the inconsistency of sometimes using one, and sometimes three, -letter prefixes. And I stil favour prefixing controls (txt, cbo).

In particular, would you name a module-file 'basMyMain.vb'? And would you name the Module within this file 'modMyMain' or 'basMyMain'?

Andy.

[HansV]

I still use (mostly three letter-)prefixes, I find they make code easier to maintain. I'm not rigorous though, I'll happily use single-letter variables such as i or n as loop counters:

For i = 1 To 1000
...
Next i

because I find

For lngLoopCounter = 1 To 1000
...
Next lngLoopCounter

somewhat cumbersome. I generally give code modules the prefix 'bas', this avoids having a module with the same name as one of the procedures or functions (that would confuse VB/VBA). I've frequently seen questions here and elsewhere about macros refusing to run because someone created a macro named DeleteRows in a module named DeleteRows.

[agibsonsw]

Thank you Hans.

[John Gray]

One convention that seems to me to be very ugly is the prefixing of variable names by an underscore, _

Of course with BATch files you can use meaningful variable names like 'log'

Code: Select all

set log=%~dp0Logs\%computername%_%~n0_Profile_%username%.log

[agibsonsw]

Ta John.

Double-underscores are worse __suchas. In some languages these represent system variables, but some authors use these for their variables - which is naughty.

Still not quite decided with VB.Net. I'll use three-letter prefixes for variables and controls, and frm for forms, but I won't use an extra letter for scope - the IDE and intellisense negates this requirement.

Modules in particular were confusing me. That is, should I name the file 'basUtils.vb' and the Module 'modUtils'? But I now see that Modules are largely redundant in .Net.

I welcome any further advice. Regards, Andy.

[HansV]

I'd use either basUtils.vb and basUtils, or modUtils.vb and modUtils, but just use what you feel comfortable with.

[agibsonsw]

I'd use either basUtils.vb and basUtils, or modUtils.vb and modUtils, but just use what you feel comfortable with.

Thanks. Think I'll use 'basUtils.vb' to distinguish general code files from Classes. Might still use 'modUtils' for the Module, but I'll limit the use of Modules to globals and Main().

This guy wants advice on this subject; I'll describe my preferences/standards on this subject (now that I've made up my mind ) and perhaps point him at a couple of web sites. Of course, I shall emphasize that the pattern adopted is not the significant thing - persuading people to use it consistently is more important.

Regards, Andy.

[ChrisGreaves]

... naming conventions in general,

I think the most important thing is to adopt, or (not as good) invent a naming convention, and stick to it.

Whether you preface your module names with "mod" or "bas" doesn't matter as much as prefacing them with something.
I prefer strings to be prefaced with "str", while my superiors seem to go with "z", but when I'm reading code and see "z"s all over the place, at least I know that z-means-string - if the author is consistent in applying their chosen convention.

I based my practice on The Reddick VBA (RVBA) Naming Conventions

[agibsonsw]

Hello again.

@Chris. Thank you; yes, I was brought up on Reddick but the consensus seems to be that it is too unwieldy (read long), and parts of it are unnecessary, with .Net. I found a page which updates it for .Net but I've lost the link for the moment.

BTW It seems I can't completely discard Modules in VB.Net anyway, as I can't declare a constant in a Namespace (although I can declare an Enum(eration), strangely).

[ChrisGreaves]

... Reddick but the consensus seems to be that it is too unwieldy (read long),

I Agree entirely!
It reads more like an academic paper than a pizza-munching coder's guide.
But then I figured I'd take what I needed and stick with it.
From memory I use the following prefixes and they account for, probably 99% of my identifiers (data and functions):
str, lng, dbl, int, wks, wbk, doc, rng, maybe another half-dozen.

That's why I think that adopting a naming convention, any convention, and sticking to it works (for any language). Some poor sod trying to decipher my VBA code would need a slip of paper with a dozen prefixes stuck to the monitor for 60 minutes, and by then would have unlocked the key to 99% of the work - providing that I've been consistent!

[agibsonsw]

From memory I use the following prefixes and they account for, probably 99% of my identifiers (data and functions):
str, lng, dbl, int, wks, wbk, doc, rng, maybe another half-dozen.

wbk - surely 'wkb'

I quite agree for Office and VBA, and with Access: tbl, qry, frm, txt, cbo, cmd, etc.. No problemo! But VB.Net presents a different outlook (excusing the pun ). Files, Namespaces, Modules, Classes, Properties, Parameters, etc., etc..

I think I'm quite happy to stick with prefixing variables, controls and forms - it's what I'm used to anyway. Most everything else can be dealt with by its "Context". But I think I'd like to prefix code modules with 'bas', to distinguish (and group) them from Classes.

I've got some of their code and the naming is a bit 'tangled'. In particular, they have some class properties called: FormatType, FileName, fileStream. The editor can cope with this, but I'm very anti. Actually, it irritates me - I wish people would show just a little more imagination.

Regards, Andy.

[ChrisGreaves]

From memory

wbk - surely 'wkb'

Andy, what part of "from memory" didn't you understand?

... VB.Net presents a different outlook ... code modules with 'bas', to distinguish (and group) them from Classes.

I've seen "cls" for class modules, "frm" for forms which, I think I've been told (see "memory" above) are really special cases of classes ...
If someone used "gui" instead of "frm" for forms I'd be happy - as long as they used "gui" throughout the project.

I've got some of their code and the naming is a bit 'tangled'.

This sounds like poor writing.
My claim is that as long as a naming convention is consistent, it will be comprehensible.
Of course, if they've used prefaces like "Mickey" and "Mouse" and "Minnie" and "Fido" we are all up a creek, but otherwise I'd think it would be a few minutes (I said 60 before) work to fathom out the prefaces and then away we go.

I agree with you too about context. Small manageable procedures that, let's say, deal with strings are going to be chock-a-block with string and integral variables, very few other things ...


(later)Bingo!My point is, I think, made.
You understood "workbook" from my typo, right?
If I had used 'wkb' throughout a project, your brain would think of it, still, as a workbook, correct?

[agibsonsw]

@Chris. Anyone order a WorbCook?

A form is a class but, as it's a special (pre-built) one, I favour 'frm' - particularly coming from an Access background.

The consensus seems to be, and I agree, that in an OOP language the prefixes 'cls' and 'obj' are overkill; everything is a Class or an Object anyway, even a variable .

(I know VBA is kinda OOP, but let's not go down that road!)

Thanks for the input. Andy.