Coding Convention Questions #3 (Procedure Naming Conventions)
Hungarian and Reddick are good at providing a model for naming variables & constants in your code. However they don't cover how to name procedures.
1. Does anyone know of any naming convention for procedures? If so, could you please provide a link to a webpage on it?
2. Have you come up with your own naming convention for procedures? If so, would you mind sharing it with us?
*******************************************************
HELP WANTED! (Links to Forum threads)
Trying to create reusable code for Custom Events at Workbook (not Application) level
*******************************************************
I name modules by core functionality followed by a terse description. Potpourri:
combinCombinAndPermut.bas
combinComboSeq.bas
combinDeBruijn.bas
combinIndefiniteForLoops.bas
combinLexOrderCombos.bas
combinLexOrderPerms.bas
combinPermuteString.bas
combinRandomWalk.bas
combinXtremeVBTalk.bas
cryptoVigenere.bas
fileExportToTabFile.bas
fileExportToTextFile.bas
fileFile2Str.bas
fileIsFileOpen.bas
fileListFiles.bas
fileMakeDirTree.bas
fileMergePDFs.bas
fileOpenWkbWritable.bas
filePlaySound.bas
fileUseFileSystemObject.bas
financeAllocateByMonth.bas
finAPY2APR.bas
geoGeoFuncs.bas
gfxColorConversion.bas
lookupLookup2D.bas
mathBaseConversion.bas
mathBinarySearch.bas
mathCircumcenter2D.bas
mathContinuedFractions.bas
mathConvolve.bas
mathCRC32.bas
mathCubicSpline.bas
mathDblHomo.bas
mathDMS2Deg.bas
mathDrawDown.bas
mathDyck.bas
mathERF.bas
mathExpPricing.bas
mathFibonacci.bas
mathFireCode.bas
mathFisherExact.bas
mathFloatingPoint2Byte.bas
mathFreeformArea.bas
mathGcdLcm.bas
mathKappa.bas
mathKendallTau.bas
mathLiteralArray.bas
mathMarginDiscountPrice.bas
mathMatrices.bas
mathModularInverse2.bas
mathParabola.bas
mathPartitions.bas
mathPoissonInverse.bas
mathPolylineIsect.bas
mathPrime.bas
mathProbabilityOfRun.bas
mathQuaternions.bas
mathRand.bas
mathRandSeed.bas
mathSignDigitRnd.bas
mathSimpsonIntBetaDist.bas
mathSimpsonIntegrator.bas
mathStDev.bas
mathTrig.bas
mathVec2.bas
mathVectorLib.bas
mathWeightedCorrelation.bas
mathWGS84ToOSGB.bas
mOverrideBobUmlas.bas
regexFuncs.bas
sortDeDup.bas
sortIndex.bas
sortInsertion.bas
sortQuickSort.bas
sortSortRectangles.bas
sortStringSorts.bas
strCatenate.bas
strEditDistance.bas
strJaccardIndex.bas
strJoin.bas
strKindaLike.bas
strLenLeftMidRight.bas
strLongComSubstring.bas
strPadNumbers.bas
strPattern.bas
strShowBinary.bas
strSpellCheck.bas
strSpellDollars.bas
strSplitText.bas
strStr2Lng.bas
strWBS.bas
sysFileSearch - Mehta.bas
sysGetDriveSerialNumber.bas
sysMeasureWindowSize.bas
sysPath2UNC.bas
sysSafeArrayInfo.bas
uiProgressMeter.bas
utilExcelDiet.bas
vbaNumberCodeLines.bas
vecPlaneAlgebra.bas
xlAddSpacesInFormulas.bas
xlAggregateArray.bas
xlAlignKeys.bas
xlCellColor.bas
xlCheckIdle.bas
xlCommentFormulas.bas
xlCompareWks.bas
xlExcessFormatting.bas
xlFindAll.bas
xlFindLastCells.bas
xlFindLiteral.bas
xlHiddenNames - Pearson.bas
xlInterpolators.bas
xlKeepLinesTogether.bas
xlListCommandBars.bas
xlLiteralArray.bas
xlMakeDynRanges.bas
xlMakeRelNames.bas
xlMergeStyles.bas
xlPackCells.bas
xlPageNumber.bas
xlPeakActivity.bas
xlRangeColorIndex.bas
xlRangeSetAlgebra.bas
xlSheetMap.bas
xlShowChanges.bas
xlSquareCells.bas
xlSum3D.bas
xlVHLookUp.bas
Entia non sunt multiplicanda sine necessitate
Hi shg. I was seeking conventions for procedure naming (e.g. subs, functions, properties) not modules...Originally Posted by shg
I can only offer the simple convention I learned from Tom Demarco back in my FORTRAN programming days:
verbObject or verbAdjectiveObject
This has worked for me for 30+ years, always provides meaningful procedure names, and usually keeps me from having to read the code to find out what a procedure does; works for modules and variable names, too. It even works a lot better these days when we are not limited to 6 or 7 character names! Makes it soooo much easier to enter code, too! Some examples:
sortNames not Name_sort
colorWorksheetCell not CellColor (Does this set a cell color, return a cell color, or tell you which model cell phone you have?)
setXaxisProperties not Xaxis (What on Earth does this do?)
createChart or createControlChart not Chart or ControlChart (What does this tell you? How much information is in the name???)
aaa=callProcedure() tells me it is a Function.
callProcedure tells me it is a Sub.
Look up a few lines and see that Dim aaa as Variant tells you aaa can contain just about anything.
If you need vnt_aaa to keep from scrolling up a long way to find out what's going on, your procedures have too many lines of code! In all but rare cases, the code for any module should fit on your monitor without scrolling. Otherwise, others will struggle to understand and maintain it...
Dim aaa as Long tells me that callProcedure returns something that can be stored in a Long
Makes code easier to read, too!
I don't care if you feel the need for some common conventions such as using underscores or coding the procedure or module type in the name; e.g., mDateTime vs FormatDateAndTime (I KNOW it is a module, because it is on the Module list!), fn_Get_File_Name vs GetSaveAsFilename, strName vs filename, lng_Index vs i (everybody knows what i is when it is used in a loop counter; the context (or the code at the top of your screen) should tell you if it is Long or Byte; if you want to know the type, look at the Dim statement!
Put the Dim statements immediately before a variable the first time it is used. Why are we compelled to place them at the top of the procedure? ...probably dates back to earlier restrictions. Undenting them makes them easy to find.
If you do a good job of creating meaningful names, the rest is superfluous...
Ask yourself if a module (procedure) name tells you unambiguously what it does. If it doesn't, try again... Walter Middy and see if you can dream up a function that the name implies that is way off base.
Sorry, this went a long way from offering a simple convention for procedure names, but it all fits together to help create useable code.
Name on! ...and create readable code.
Thanks FORTRANguru. Some excellent advice here.Thanks for sharing. +1
My questions/thoughts below:
I think I should try to learn this method. The only reluctance I have is that that I have a few procedures that I group by common action by naming in the following format:
GroupGeneralDescription_Verb_Condition/DetailedDescription
(e.g. Edit1or2DArr_2Col_ConcatenateFirstNameToLastName, Edit1or2DArr_1Col_Replace_StringsToNumbers, Edit1or2DArr_1Col_Replace_NumbersToCurrency, Edit1or2DArr_DelColsConsecutive etc).
What do you advise I should rename these as? Should I abandon the grouping concept or is there some way I could implement a grouping scheme into the verbAdjectiveObject pattern?
Agree with all the above.
Just to make sure I have understood this correctly - the only way we distinguish between a sub and a function using this convention is by adding brackets after the procedure name in the calling sub? There is nothing in the naming convention which would allow you to determine whether a procedure is a sub or function just from its name only?
True, True. Which is why VBA programmers should always use Hungarian or Reddick for naming their variables & constants
There is nothing in this naming convention which would allow you to determine the type of a function from its name?
Slightly off the thread topic of procedure naming - but here's my view on this.
Personally I always feel compelled to place them at the top of the procedure. Because:
- There is no speed improvement by declaring these 'Just In Time' (Because VBA compiles the procedure code - in effect - at runtime IIRC?)
- I can see at a glance how many variables I am using in the procedure. This helps to see if I am using too many variables - if I am then time to create a few sub-procedures.
Expanding on my opening post - I am looking for the requirements below before adopting any procedure naming convention. I doubt there is any naming convention - even homemade - that covers all of the requirements below. So I may have to create my own using the best points of each convention provided to this thread. So keep them coming!
(In ascending order of complexity)
- The procedure name should identify what the procedure does. (Covered by FORTRANguru)
- The procedure names should follow a consistent naming pattern. (I like the verbAdjectiveObject idea provided by FORTRANguru. However I would be interested in any other grammar naming patterns)
- The procedure name must identify if the procedure is a Sub or Function.
- If a function, the procedure name must identify what data type is returned. (I have considered naming the function using the variable naming conventions but I rejected that idea as I don't want to confuse variables with functions. Maybe if the function name included the variable datatype tags?)
- If the procedure is a sub procedure of a main procedure and it is not generic enough to be reused by anything else then ideally the name of the sub procedure should somehow indicate a link with the main procedure. (Probably by having (part of) the main subs name as a prefix/suffix to the sub procedures name?)
- I often have subs that I set up as boolean functions. (The idea of this is that the function can return a True/False value if the procedure failed or not). If possible, I'd like some way to distinguish these 'boolean subs' as being a different animal to your standard sub or function!
BTW I am leaving Properties out of the convention. I will have to look a separate naming convention for properties another day.
Last edited by mc84excel; 03-30-2014 at 06:17 PM.
#4, 5, 6 - why? I think this will decrease legibility you will have gained from #1, 2, 3
- Please remember to mark threads Solved with Thread Tools link at top of page.
- Please use code tags when posting code: [code]Place your code here[/code]
- Please read Forum Rules
I'm with Izandol, what's the point in all that? I don't get it, I can sort of see the point if you code in a text editor, you use an IDE so you don't have to track all that stuff. If you try to include all that you end up with totally incomprehensible long winded names for everything and there's no point - just make your variable names descriptive so you know what they do and let the IDE take care of everything else, if you ever need to know detail about an element in your code, use quick info.
For a more pragmatic view on naming conventions, have a look here http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx
#4 & #5 - Improve Readability (same reason for using Hungarian or Reddick conventions)
#6 - Hmmm. Now that I re-read it, I think you are right (re decrease legibility)
Hi Kyle, good to hear from you again.
See my previous reply to Izandol
Which is probably the argument used by coders that don't adopt Hungarian
Thanks for the suggestion. I started to read it. Up until the point where it said "DO NOT use Hungarian notation."
Last edited by mc84excel; 04-01-2014 at 07:02 PM.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
LinkBack URL
About LinkBacks
Register To Reply
Bookmarks