Are naming conventions a good idea? 1

[LARiot]

Are using naming conventions a good idea? I've been using them for years and they don't seem to add any real benefit. They increase the length of the variable, control or object name making it harder to read code. They're also a pain when changing data or control type.

Differentiating between queries and tables of the same name in code is the only use that comes to mind.

Any comments? Thanks.

 

[fumei]

What would be your alternative?

I am not sure I would agree that naming conventions make it harder to read code. Why do you say that?

The main purpose of naming conventions is to, in fact, make it easier to read code. Especially for someone else.

Perhaps if you expanded on what you mean by naming conventions.

For example: Client tells me nothing. sClient at least tells me it is a string. sClientName tells me all I need to know.

Is that using a naming convention?

It certainly can be debated (and has been) that the standard prefixes (str, bol, int etc.) may not needed. I am inclined to think that knowing the data type is a good thing. Informative names are definitely a good thing.

Gerry
My paintings and sculpture

 

[GlennUK]

I'd also ask what your alernative would be? Or do you just mean that overlong names make code hard to read; for example ( here's some I had to decipher recently ):

    With Worksheets(strWorksheetName)
    
        For iCurrentRow = FIRST_DESTINATION_ROW To iCurrentMonthRow
                    
                .Cells(iCurrentRow, NBP_REALISED_FIXED_COLUMN).Value = Worksheets(TARGET_PNL_WRKSHEET).Cells(Target_PnL_Row + NBP_FIXED_ROW_OFFSET, REALISED_COLUMN).Value
                .Cells(iCurrentRow, NBP_REALISED_FUTURES_COLUMN).Value = Worksheets(TARGET_PNL_WRKSHEET).Cells(Target_PnL_Row + NBP_FUTURES_ROW_OFFSET, REALISED_COLUMN).Value
                .Cells(iCurrentRow, NBP_REALISED_OPTIONS_COLUMN).Value = Worksheets(TARGET_PNL_WRKSHEET).Cells(Target_PnL_Row + NBP_OPTIONS_ROW_OFFSET, REALISED_COLUMN).Value
                .Cells(iCurrentRow, NBP_REALISED_SWAPS_COLUMN).Value = Worksheets(TARGET_PNL_WRKSHEET).Cells(Target_PnL_Row + NBP_SWAPS_ROW_OFFSET, REALISED_COLUMN).Value
                .Cells(iCurrentRow, ZEB_REALISED_FIXED_COLUMN).Value = Worksheets(TARGET_PNL_WRKSHEET).Cells(Target_PnL_Row + ZEB_FIXED_ROW_OFFSET, REALISED_COLUMN).Value

Cheers, Glenn.

Did you hear about the literalist show-jumper? He broke his nose jumping against the clock.

 

[HarleyQuinn]

I can certainly say I'd prefer to try and decipher code where the coder had used intCurrentCount as an integer rather than calling the same variable ClintEastwood (as I have seen in inherited code before).

HarleyQuinn
---------------------------------
Get the most out of Tek-Tips, read FAQ222-2244 before posting.

 

[xlbo]

yup - I think that which convention you use is up to you but it is useful to have a convention.

I don't tend to use full identifiers - for instance, I use i = int, s = string, What is more important is the naming of the variables so that they are

a: not too long
b: easily understandable

iCol for instance is easily understandable to me as an integer representing a column index. sUserName is more understandable than sName or sUName but sNameOfUserGotFromUSerID is too long (although very clear).

At the end of the day, you should use what works for you but do use something !!

Rgds, Geoff

We could learn a lot from crayons. Some are sharp, some are pretty and some are dull. Some have weird names and all are different colours but they all live in the same box.

Please read FAQ222-2244 before you ask a question

 

[fumei]

Wow. "ClintEastwood"??????

And Glenn, some of those are hilarious.

Really, I think the bottom line, as has been stated, is to have code that is comprehensible. Starting with your own comprehension - I have seen code that a year later the originator had trouble figuring out what it meant.

Second of all, for anyone else that may end up having to deal with it.

One could easily make up some personal standard which may be useful for the originator, but if it seems like gibberish to anyone else....it IS gibberish.

I don't think anyone has to be rigid and stuck. Naming can be flexible, but it should be consistent, not too long, and above all comprehensible.

I saw iTlNmDyHr.

This was for Telephone Number Daytime Hours.

Sheeesh.

Gerry
My paintings and sculpture

 

[HarleyQuinn]

Gerry,

The guy who coded the ClintEastwood variable tried to pass off that he did use a naming convention in that the name did contain the type, ClintEastwood.

HarleyQuinn
---------------------------------
Get the most out of Tek-Tips, read FAQ222-2244 before posting.

 

[AnotherHiggins]

Well at least he had that going for him. I once saw BarneyThePrupleDinosaur used as a variable. Funny, but not very helpful.

[tt]_____
[blue]-John[/blue][/tt]
[tab][red]The plural of anecdote is not data[/red]

Help us help you. Please read FAQ181-2886 before posting.

 

[AnotherHiggins]

Oops - I meant BarneyTheP[red]ur[/red]pleDinosaur.

BarneyThePrupleDinosaur just doesn't make any sense.

[tt]_____
[blue]-John[/blue][/tt]
[tab][red]The plural of anecdote is not data[/red]

Help us help you. Please read FAQ181-2886 before posting.

 

[LARiot]

I remember a time when our company took over a project from another and you could really see how they felt about it from the code. They were using expletives as variables. It was amusing.

Maybe I'll stick to shorter naming convention prefixes which will make it easier to read. I'm an advocate of keeping the code as simple as possible. Still it's a hassle if they have to be changed.

BTW, if you ask me they should make the prefix determine the data type. As in if you type Dim strVariable that's enough code for the compiler to understand vs. adding As String.

 

[Asspin]

Try to write code so that if you drop dead tomorrow, a coworker could start from where you left off without having to figure out what you did. From that view point, using some form of common naming for variables would be a good idea.

Dan

 

[LARiot]

Drop dead tomorrow? Hmmm... have you been talking to my users?

 

[fumei]

I think Dan has got it right. Write it as if someone may take it on...NOW.

BTW, if you ask me they should make the prefix determine the data type. As in if you type Dim strVariable that's enough code for the compiler to understand vs. adding As String.

Perhaps, but that would be a rigid have-to kind of naming convention, wouldn't it.

I think THAT would be resisted more than anything currently in place.

It would mean you could not use sVariable. You would use strVariable. Hmmmm, that would go over like a lead balloon. Can you hear the conspiracy theory against Microsoft? The "fascist" forcing of code writing?

Would be handy though. Even if the compiler would accept "standard" prefixes, but still allow explicit data type statements.

Dim strVariable - makes a String (not a Variant)
Dim sVariable As String - makes a String explicitly
Dim sVariable - makes a Variant

Hmmmm, I don't know. Looks too easy to make lots of Variants by mistake.

Nope, it may not be perfect, but the way it is seems a reasonable compromise.

If a coder is consistent and reasonably comprehensive in names, then 99 times out of 100 another coder can figure it out.

As for using expletives...I have seen this. Rather sophomoric. Any time I have ever seen it, the code was poorly written.

Gerry
My paintings and sculpture

 

[Asspin]

I once took over a project at work. The guy who designed it used horrid names for the variables. It was so random, i rememeber one of them was 'ShowMeTheMoney', that really didn't tell me anything about it. I ended up having to go through all the code and use normal variables just so I could read the stupid thing. I am all for naming conventions!

Dan

 

[xlbo]

Bear in mind that for the more common variable types, you can use the "Type Declaration Character" for each to save you typing "as string" or whatever eg@

% = integer
& = Long
Currency = @
Double = #
Single = !
String = $

So

dim iVal% = dim iVal as integer
dim sName$ = dim sName as string

etc etc

Rgds, Geoff

We could learn a lot from crayons. Some are sharp, some are pretty and some are dull. Some have weird names and all are different colours but they all live in the same box.

Please read FAQ222-2244 before you ask a question