Feedback

Thank you to the following people for their comments and suggestions, so far:
Patrick O'Beirne - @ExcelAnalytics - sysmod.com
Jon Peltier - @PeltierTech - peltiertech.com
Jordan Goldmeier - @Option_Explicit - excel.tv
Rory Archibald - @roryarchibald
Paul Kelly - @MacroMastery - excelmacromastery.com


I will be making changes based on this feedback
The word "Always" will be removed because there are always exceptions to every recommendation.


2) Always try to declare your variables at the top of the subroutine or function.
FEEDBACK: Variables should be declared where they are being used, rather than at the top.
I will change this to "Try to declare your variables where they are being used"
Some variables might belong at the top but others are should be declared just before they are used.
This makes refactoring the code easier.


4) Always try and declare one variable per line.
FEEDBACK: Related variables should be declared on the same line.
I will change this to "Try and declare your variables on different lines when it makes sense".
If the variables have the same data type or they are related, then they should be on the same line (max 6).
This makes refactoring the code easier.


5) Always prefix your variables with a data type indicator.
FEEDBACK: Has been mixed.
Is there any real advantage ?
Does this make the code harder to read ?
Does it really help prevent type mismatch errors ?
Using Hungarian notation in other languages is definitely not necessary.


16) Always use the keyword Call to call your procedures (and functions).
FEEDBACK: The Call keyword is a legacy keyword from the olden days and should not be used.
I will change this to "Do not use the Call keyword when calling procedures (and functions)"
This syntax actually comes from the days of BASIC when every line had to start with a keyword.
When you transfer control to another subroutine you use this syntax:

Sub Testing() 
   MySub
   MyFunction "arg"
End Sub

The following syntax also works, but is considered redundant now, which is a shame. because it does make your code more readable.

Sub Testing() 
   Call MySub
   Call MyFunction("arg")
End Sub

Additional Comment:
Using the Call keyword means that your arguments must be enclosed in parentheses, which some people like.
It is definitely worth understanding how and when parentheses are used and required.
You have to include parentheses when calling functions that return a value.

sReturn = MyFunction("text") 

You have to include parentheses when calling methods that return a value.

Set wbk = Workbooks.Add(Template:="C:\temp\myFile.xlsx") 

You often see this MsgBox syntax, which is bad practice, and very misleading.
When you include a space before an open bracket, the expression gets evaluated first.

MsgBox ("hello world") 

This should be either:

MsgBox "hello world" 
Call MsgBox("hello world")

25) Always use Class Modules when it makes the most sense.
FEEDBACK: Has been mixed.
How much are classes used ?
If you just want a group of properties inside a single object (to use as a data container) then a Class may be excessive.
For simple objects that just contain properties, consider a User Defined Type instead.
For complicated objects with private methods and events then use a Class.


30) Avoid using Application.ScreenUpdating = False.
FEEDBACK: This definitely needs to be removed and replaced with something else.
Let us know what you think should be added here instead ?



Suggestions:
*) Prefixing function names with "fn" or "fx"
*) Prefixing function names with "sfn" or "sfx" AND including a data type prefix indicator at the start


assign initial values to variables once they are declared.
validate data types of any subroutine arguments before they are used.
group your constants into enumerations when they are related.
change your error trapping option to "break on all errors" when you want to catch both handled and unhandled errors.
don't exit complex loops prematurely (use Exit Do, Exit For carefully).
avoid loops when searching in Ranges and Arrays.


© 2024 Better Solutions Limited. All Rights Reserved. © 2024 Better Solutions Limited TopPrevNext