VBA Limitations - Restrictions (1 Viewer)

[KitaYama]

Having nothing to do, I decided to run MZ-Tools' Review Quality on one of my databases.
In Programming Rules Review, I'm receiving some weird errors I've never heard of.

• The number of parameters of a method cannot be greater than 5 (Receiving on API with more than 5 parameters)
• The number of parameters of a method cannot be greater than 5 (Receiving on functions/subs with more than 5 parameters)
• Class fields cannot be declared with the Dim keyword (Receiving on Dim WithEvents oForm As Access.Form ---> on top of class modules)
• Method variables cannot be a single letter (Dim X As Integer)
• Classes cannot have more than 1000 lines of code
• Modules cannot have more than 1000 lines of code
• Enum items names cannot start with the name of the parent enum

Can anyone confirm if any of these points are valid? Or they're simply MZ-Tools rules and not VBA.....
(specially point 3 in above list)

Thanks.

 

[Edgar_]

It sounds like the opinion of the developer trying to enforce some "best practices". It's not that it's wrong, it's advice to let you know how you can have more maintainable code.

BTW: Never used the tool, I'm just saying.

 

[KitaYama]

Just as a test I corrected my classes from

Dim WithEvents **** As ****
to
Private WithEvents **** As ****

It seems MZ-Tools is happier now.

 

[The_Doc_Man]

I believe the limit for lines of code in a module is 65535 or 65536. Your "quality control tool" has someone else's standards in its "head" - and as far as dealing with parameters, MS has APIs that need more than 5 parameters. So let's just say you should take their recommendations with a grain of salt. (Don't know if you know that English idiom... it means "with skepticism.")

 

[KitaYama]

I believe the limit for lines of code in a module is 65535 or 65536.

I had a feeling it should be controlled by the number of characters in a module not the number of lines. To me a module with each line having 500 or more characters should occupy more bits than another module with the same number of lines but each line in 20 or less characters.
As I said, it was just my assumption.

Your "quality control tool" has someone else's standards in its "head"

Even though I'm the only user of this PC and MZ-Tools is only used by me, but that was the first thing I could think of. I tried to change those settings, but it seems it's hard coded into MZ-Tools. All settings are grayed out and I'm unable to change them.

Don't know if you know that English idiom... it means "with skepticism."

I have two good friends. Google translate and another paid site for learning English. Thanks for making it easier to learn a new phrase without asking them.

 

[Josef P.]

You can change or deactivate the rules for Quality Review in MZ-Tools as you wish.

 

[KitaYama]

You can change or deactivate the rules for Quality Review in MZ-Tools as you wish.

I didn't know I have to expand the check items to be able to edit the default values. I had it as following.
Your image solved the problem.

@Josef P. One last question if you don't mind. MZ-Tools comes with pre-set values. Is there any specific reason for the following two cases?
I don't think they have added these two rules out of blue.

• Class fields cannot be declared with the Dim keyword
• Enum items names cannot start with the name of the parent enum

thanks.

 

[Uncle Gizmo]

you should take their recommendations with a grain of salt. (Don't know if you know that English idiom... it means "with skepticism.")

Definitely English but in the UK, the root of English, we don't normally say "grain of salt" we say "pinch of salt"

(qué for Colin to join the thread to berate American members)

 

[isladogs]

Just to be clear, that's the other Colin. I'll just pick up on the 'cue'

 

[sonic8]

Can anyone confirm if any of these points are valid? Or they're simply MZ-Tools rules and not VBA.....

Yes, these points are valid.
These are not hard limitations by the VBA environment. They are guidelines to write maintainable code that is easy to read and to extend/modified with low risk of errors on the side of the developer. The default set of the code quality rules are a good starting point, but you can modify them to your personal opinions/preferences. We use these default rules but also added some additional rules on top.

 

[KitaYama]

@sonic8 Million thanks.

 

[CarlosQ]

Hi,

The programming rules reviews supplied are just samples of good programming practices that you can follow, customize or ignore (just deactivate the rule or delete it). For example:

- Files should not have too many lines...
- Subs/Functions should not have too many lines (how many depend on each team...)
- Field should use Public/Private/Friend scopes. Maybe not everyone knows that "By default, variables declared with the Dim statement in the Declarations section are scoped as private."
- You may want to use enum values in the form Color.Blue instead of Color.ColorBlue
- You may want to avoid too many parameters (if a procedure uses too many, maybe you want to define a type to group them, or maybe your procedure is doing too many things and should be refactored into smaller procedures)
- Etc.

In short, while the compilers of VBA (and VB.NET, and C#, etc.) allow any valid language syntax and big limits, not everything is a good practice. There are thick books such as Code Complete, Code Clean, etc. devoted to good programming practices.

 

[isladogs]

Thanks for clarifying Carlos. For anyone who isn’t aware, Carlos Quintero is the creator of the excellent MZ-Tools. He is also giving a presentation to Access Europe on the many very useful features of his product. That will be on Wed 7 Feb 2024. More details at https://isladogs.co.uk/aeu-24/