DWUTKA at marlow.com
DWUTKA at marlow.com
Mon May 16 17:08:33 CDT 2005
Okay, now I can't tell if you are being sarcastic or not. If you think module AND global level variables are bad practice....well, that only leaves procedural, and you might as well stop programming.... You CAN be 100% sure that you don't have unhandled errors. Put Error handling procedures into every procedure! Now that is a GOOD practice. Admittedly, I don't do that myself, not on personal stuff...... (now THAT, I'm willing to concede is a bad practice! <grin>). If you can be sure you're not using global variables (or modular level), then you could also be sure that you have no unhandled errors! Maybe you don't understand this, so I'll explain this for you, please don't think I'm trying to be obnoxious, but if you don't understand error handling, then it would explain your statements below. One, If you start every procedure (Function or Sub (and Property statements in classes)) with On Error statements, you cannot have an unhandled error. On Error Resume Next will simply let every error just pass right through the system. Obviously...not smart, but sometimes it is actually necessary. On Error Goto Well, with that statement, you can force the code to go to an 'Error Handler', where you can do all sorts of things. You can accomodate an error (sometimes, you program expecting an error to occur, so getting into the errorhandler is by design in those cases). Let's say that you put in ErrorHandling when a user puts text data into a numeric field. Now, let's say that you might expect the user to type 'one', instead of '1'. You may decide to create a text to number function, so that the user never knows something is wrong, you fix the issue, and continue your code. To do that, your errorhandler has to determine if the error applies (wrong data type in that case). Even if you don't know what type of error it is, you can always display the error number and description, and move on. (Use a Select Case statement in the errorhandler...and include the Case Else statement). Either way, if you have Errorhandling in your procedures, you'll never have the code stopped by the user (unless you let them get into your code!). The only time this does NOT apply, is when you have an exception fault. Yes, you can cause that from within VBA...don't ask me how, cause I'm drawing a blank, but I've done it before! <grin> In cases like that, the Error handling isn't triggered....instead, ACCESS gets shut down. If that happens, it doesn't really matter that the global variables will be lost, because EVERYTHING is lost! Does that make sense? Drew -----Original Message----- From: Dan Waters [mailto:dwaters at usinternet.com] Sent: Monday, May 16, 2005 4:45 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Global Variable Drew, Globals are bad practice because: If I use global variables and I have an unhandled error I can be 100% sure that my global variable value will be lost. I cannot be 100% sure that I won't have unhandled errors. I can be 100% sure that I'm not using global variables. If I could be 100% certain that I won't have unhandled errors, then global variables would be a good practice. Dan Waters PS - Based on what you pointed out about module level variables, I think using them is bad practice too! See - I learned something new because you told me 'why'! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Monday, May 16, 2005 3:53 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Global Variable Right, but it's a jaded, and actually illogical proclamation that Globals are bad practice. Let's look at this Dan. What's the argument that they are bad practice? Because stopping the code makes them lose their values. Okay, that is true, but does it apply to anything else? It sure does, but the 'general consensus' folks are only worried about Globals. Why? Who knows. Let's test our theory. Make a form, and put three command buttons on it. Now paste the following code behind the form (and set the events for the form's load, and the command buttons 'On Click' events. Option Compare Database Option Explicit Private intSomeNumber As Long Private Sub Command0_Click() intSomeNumber = 5 End Sub Private Sub Command1_Click() MsgBox intSomeNumber End Sub Private Sub Command2_Click() Dim x As Long x = 1 / 0 End Sub Private Sub Form_Load() intSomeNumber = 1 End Sub Open the form, and hit the first button. Now hit the second button. We get 5. Close the form, open the form, and hit the second button. We get 1. All as expected right? Now hit the third button...uh oh, an error, it's not handled. Now hit 'end' (which stops the code from executing). To the user, the error is 'over'. Nothing to worry about, right? Wrong, we just lost ALL variables. Hit the second button now, we get a big ZERO!!!! Now, if we say that global variables are bad practice, because they lose their value when the code is stopped from an unhandled error, shouldn't we also say that module level variables are bad practice? If we dimensioned intSomeNumber as 'Public MyNumericValue', which takes a module level variable, and makes it a PROPERTY of the form, we get the same results. The stop in the execution of the code cause the property to lose it's value! So should we also apply the 'bad practice' principle to class properties? Of course not, because we'd be left with procedural level variables, which, by the way, ALSO lose their values when the code is stopped, but that is completely unnoticed, since the procedure being run just stopped! Now, let's change Command2_Click() to this: Private Sub Command2_Click() On Error GoTo ErrorHandler Dim x As Long x = 1 / 0 Exit Sub ErrorHandler: MsgBox Err.Number & " - " & Err.Description Err.Clear End Sub Now, same process, and look at that...the values are still there. (so would the values in a global variable, and a class property). Now, tell me Dan, which is bad practice? Global Variables, or missing/improper error handling? Eh? Now for why I get into this type of discussion, and why I may appear to 'rail' against the norm. Let's take Jim Bob the new developer. He's just starting out in coding, but is a very fast learner. He's tearing through using classes, and creating custom events, and is progressing at an amazing pace. He's done this, of course, by being an avid reader on AccessD. Now, he's seen posts from people like Charlotte, and JC, people who's coding and experience is nothing but impressive. He sees a post by them that says 'Don't get carried away with them, they are considered bad practice in general.'. Now, whether or not Jim Bob the Developer has specifically had one of them help him with his code, he has more then likely made use of the knowledge he has gleaned from their posts. Now he is in a situation where using Global variables is the best solution. He may have to use a lot of them. But it all works just fine, and does exactly what it's supposed to do. But wait a minute, people he respected, and simply took their word as law in the coding world said that it was 'bad practice'. There must be something he doesn't know about global variables. It's 'iffy'. That's the concept that comes across. So he doesn't use Global Variables. Instead, he writes 5 times more code (ya, look at the typing difference between Global XYZ, and a function to handle preloading etc....) or more, and now his code is NOT as efficient as it should be, and he's wasting time. What's worse, is that when Jim Bob the Developer starts posting to AccessD as Jim Bob the experienced and world renowned developer, he is going to tell Jim Bob Junior, the 'new' developer that Global Variables are 'bad practice'...and the cycle continues. This particular 'bad practice' issue is fed by the misconception that there is other alternatives that are just as good as a Global Variable. Not really. Pulling a value from a table takes a lot more time then just pulling it from memory. As I've just shown you, even module level variables will lose their values with unhandled errors, so you can't even keep a 'global form' with values, unless you put them as values in a textbox. So...values in a textbox....that's a viable option, right? Wrong. It's now where near as efficient as an actual Global variable. First of all, you have all of the overhead of a form being opened. Then, when getting the value, you aren't going to a register in memory, you are going to a form, then a control, then a property on that control. Granted, even on 100 mhz machines, the speed and memory issues are inconsequential, but on a larger scale, it becomes much more apparent. And, there are uses for global variables that are MUCH more difficult to try and replicate with another method. For instance, I developed an inventory system, where all sorts of things were done to the inventory. If a user changes anything in the inventory, I used a custom class, set as a global variable, which was used for ALL transactions. Whenever something was changed, it raised events to alert to the various changes. Anything that used the inventory class would immediately refresh it's data when the event was raised. Without having that class as a Global Variable, to do the same type of 'live update' on everything would have been a very daunting task. Each new process would have to 'trigger' every existing process, and all of the existing processes would have to be setup to trigger the new ones. With a Global 'class', only the new stuff needed coding, as you would want, and all of the old stuff just 'knew' what was happening. Sure, I know the people that preach 'bad practices' probably won't stop, or change their preaching, but hopefully Jim Bob the new developer will see MY posts, and not pick up the 'bad practice' of thinking something is iffy when it's not. Drew -----Original Message----- From: Dan Waters [mailto:dwaters at usinternet.com] Sent: Monday, May 16, 2005 2:31 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Global Variable Drew, For me, it helps a lot to understand 'why' I should follow a particular practice. If I understand why, I can expand of what is being stated by applying the 'why' to my circumstance, and therefore learn even more! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Monday, May 16, 2005 1:50 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Global Variable You know, I think this whole debate could be avoided, again, if it was just stated that using global variables when a 'lesser' scope should be used, is bad practice. I know I get into these discussions, because I am self taught, and it takes a LOT more energy to overcome incumbent thought obstacles then it does to learn new things. Drew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Monday, May 16, 2005 12:31 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Global Variable Gustav, There are many things generally considered poor programming practice in the programming industry. Excessive use of Gotos and Global variables are a couple of examples. In general they ARE CONSIDERED (by myself and many many many other people) to be bad programming practices. Globals, like Gotos are handed down from the days of old when there was no such thing as functions, data types declarations, scope and the many other tools that make modern programming worlds above the code written 40 years ago. All of these things exist for a reason. Globals are considered poor programming practice because they expose variables to update and even overwriting by code that has no business updating that variable. It is generally accepted practice that variables should have the minimum exposure absolutely necessary to perform their function. A variable used ONLY in a specific function should NOT EVER be declared as a global variable. A variable used ONLY in a module should NOT EVER be declared a global. Microsoft and other compiler writers provide tools like variable scope for a good reason, they help minimize, and track down bugs. If a variable is private to a module then if that variable is being updated incorrectly, you at least know it is because of some code in that module. If it can be updated anywhere in the entire program then you must search the entire program when something goes wrong. Function level variables (declared inside a function) are local to the function and cannot be declared otherwise. Thus the "excessive use" of globals would include making a variable, intended for use in a module, global "just in case". I personally make it a practice to always explicitly declare module level variables private Private MyVar as SomeVarType unless there is an over-riding reason to expose the variable on a global basis. Even then I make it a practice to build a function that reads a private variable in those cases where code in other modules must be able to read the variable. Only in cases where code in multiple modules must both read and write a global variable will I expose the variable itself as a global. And even in those cases it is sometime useful to cause the write to go through a function, particularly if the variable is a computed value. Global variables is one of those issues that strikes a sensitive note with many programmers, but it is indeed widely accepted to be poor programming practice to just use them willy-nilly and for no good reason. Every tool exists for a reason and variable scope is a very powerful tool to assist the programmer in writing better code. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, May 16, 2005 12:34 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Global Variable Hi John You may like or prefer or need, or not, a global variable - that's up to everyone to decide for him/herself - but they are not "bad practice", not even in general. You may write clumsy code using globals, but not using them gives no guarantee for nice code. /gustav -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com