Nested IF/Then VS. Case Select Statement

QMDirk

Member
Local time
Yesterday, 19:55
Joined
Nov 16, 2019
Messages
52
Hey everyone. I'm looking for opinions here. I have a string of text (which is built by piecing together pre-defined variables) which represents up to 5 different variables. In all, there are 3 possible combinations of variables. On a form, there is a number 1-2, or 3 which represents the "format type". When the "format type" value changes, it is critical that the displayed text in a textbox changes with it. The text is a production code, of which there are 3 customer-required formats. Further more, once I solve the syntax issue, I have to write an IF-Then statement around all of it in order to set the Julian Day variable back one day if the form is displayed between 00:01 and 05:59 (military time) since my plant doesn't change the production code until the new day begins at 06:00am. I have the code to correct for that part, just not sure how I'm going to work it in with the rest of the page. I thought to write a Public Function and put a Case Select statement in there. the function will be called continuously as 6 production lines, over 2 shifts, are using the program's forms. The 'opinions' I mentioned, are this: given that there are only 3 different formats, would it really be that much slower than a case select statement? If not, I can work through the nested If's. It's the Case Select that I've never successfully used. Any opinions? Thanks. (PS. a lot is explained in the attachments).
 

Attachments

Hi. Sometimes, it really just comes down to "personal preferences." When an If/Then statement has more than two or maybe three options, I tend to move on to using Select Case statements. If nothing else, you could use the Select Case statement and just consider it as having graduated from using a basic If/Then block. Cheers!
 
Use Option Explicit
 
hi QMDirk,

answering a question you didn't ask:
Rich (BB code):
'this:
Format(DatePart("y", Date), "000") - 1
'should be done like this:
Format(DatePart("y", Date-1), "000")
'so math is done on the number before it is formatted
'  -- otherwise you'll lose the format and it will be a number again

agree with Uncle Gizmo to use Option Explicit at the top of all modules. You can set this as a default so that Access adds it to new modules you create in the future
vba_opyions_requireVariableDeclaration.png


like theDBguy, I agree that using If-ElseIf-Else-Endif vs Select Case statements is really preference for the logic at hand. I use both
 
To keep the code tidy, specially when the amount of code between IF and ElseIf is too much I use GoSub

SQL:
IF thisCondition=true then
    GoSub DoThis
Else
    GoSub DoThat
end if

' a lot of code here'


DoThis:
    ' My code for true'
    ......
    Return
 

DoThat
    ' My code for false'
    ......
    Return
 
hi QMDirk,

answering a question you didn't ask:
Rich (BB code):
'this:
Format(DatePart("y", Date), "000") - 1
'should be done like this:
Format(DatePart("y", Date-1), "000")
'so math is done on the number before it is formatted
'  -- otherwise you'll lose the format and it will be a number again

agree with Uncle Gizmo to use Option Explicit at the top of all modules. You can set this as a default so that Access adds it to new modules you create in the future
View attachment 81288

like theDBguy, I agree that using If-ElseIf-Else-Endif vs Select Case statements is really preference for the logic at hand. I use both
thank you so much!
 
To keep the code tidy, specially when the amount of code between IF and ElseIf is too much I use GoSub

Interesting. I have never used GoSub.
Occasionally i do use GoTo but I think both are better avoided as they can make program flow hard to read
 
you're welcome, Dirk (is that your name?)

I agree with Colin to avoid GoSub -- better to make procedures and pass parameters to them. Normally, I only use Go To when it is to go to the statements to clean up object variables and exit
 
Interesting. I have never used GoSub.
Occasionally i do use GoTo but I think both are better avoided as they can make program flow hard to read
I use GoSub because it can be used with Return to exactly return back to the branch point. But I'll keep your advice in my mind.

Thanks for mentioning.
 
The choice of a case statement or a series of Elseif's is not generally made based on speed. The choice is about clarity. The case statement is almost always clearer and easier to change. As others have suggested, you don't necessarily need to embed code in the case if that is going to make it hard to read. You can use GoSub's

Looking at your code, you seem to be using data as variable names. That is always a problem. What happens if you have to support a new company? You might want to tablize these rules so that you can create a new table entry to support a new customer and that way none of your code to build the barcode references a company. It just uses the company to look up the rule in the table.
 

Users who are viewing this thread

Back
Top Bottom