DWUTKA at marlow.com
DWUTKA at marlow.com
Tue May 17 13:35:36 CDT 2005
Not sure where that speil was going. First of all, I wouldn't dimension a global variable called strTaxID. Of course that would be bad practice. I do use standards, just not to the same extent, and honestly, the 'arguments' over standards is goofy, one shop will want one way, one will want another way. I do write stuff for other people, where you are getting that I don't is beyond me. I completely agree, misusing global variables is bad practice. Let me say that again, for the cheap seats. I completely aggree, misusing global variables is bad practice. What I do NOT agree with, is to just blatantly say that Global Variables are bad practice. Misusing anything can be bad practice. To say that Globals lose their data if the code is stopped...okay, so do module level, and for that matter, so do procedural level. To say that anyone can change the value of it...okay, same applies to module and procedural. The arguments just don't stick. By the way...I'd love the see a life dependant system built strictly in Access....... Drew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Tuesday, May 17, 2005 11:20 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Global Variable Drew, >If your app is overloaded with Global variables, if that is what you need, it is what you need. Or maybe you just have never tried very hard to do it a different way. I write some pretty large apps Drew. I have apps with thousands of lines of code, dozens of modules and dozens of classes. Yet I have a handful of globals in my apps. If they are so necessary why don't I need them? Are you special somehow that you get all the "really hard things" that just require globals? >If you are not saying that they 'go away' as an argument, why do you consider them 'bad practice' still? Because anyone anywhere can overwrite them. If a variable is "global" to a module - dimmed PRIVATE in the header of the module, then only code in that module can set / read the variable. If a variable does not need to be WRITTEN TO by code outside the module, then it should be a private variable in the module header. If objects outside the module need to be able to READ the module, then you create a public function that returns the value of the variable. Because the variable is dimensioned PRIVATE, objects outside the module cannot WRITE to the variable, but can use the function to READ the variable. That variable is not truly global, it is global to the module but read only to the rest of the project. The concept of variable scope becomes very important in large projects. Many different modules may have a variable named strTaxID for example. Yea, yea, not YOUR projects since you revile conventions, but other people's projects. Now, the strTaxID may be the company's TAXID in one module, but an Employee's TaxID in another module. By using scope and making strTaxID private to the module then anyone can use strTaxID as it is useful to them in their own modules yet not step on the usage of another module. If you just make everything in the damn world global, then strTaxID "belongs to" the first developer to dimension a variable by that name and if anyone else uses that name they "step on" the other developer's variable. Maybe they use it correctly, maybe they are sloppy programmers who don't consistently dimension a variable, depending on VB to do it at the instant the variable is used. OOOPPPps, they just trashed something. They don't trash MY something because unless it is absolutely required, and those instances are truly few and far between, I dim all my variables private and expose them exactly when and where they are needed outside of my modules. I learned a lot of things writing code for Puritan-Bennett. They make ventilators and bugs in their code kill people. Bugs in code for Aircraft control systems kill people. Bugs in interstellar spacecraft crash and burn the space craft. There are basic practices that are NOT difficult, they ARE good practice and ANYONE can learn to do them. If you do them then your code is easier to read, easier to troubleshoot and (usually) allows fewer bugs. And yea, yea, you only write code by yourself, or for small apps, or other bullshit excuses. Good programming practices are good programming practices, and poor practices are poor practices. It is very easy to make excuses, and it is not easy to be a methodical programmer, doing things "the right way" just because that makes your program (and programming) better. You pride yourself for thinking for yourself, and believe me, I applaud you for that. However there are practices that exist because the community at large have learned things, have been exposed to situations that you haven't been exposed to. By just rejecting things because "I don't see any sense in that" is quite all right when you are working on your own project for your own purposes. To do that when you are paid money to produce a product for someone else is quite another matter. Along with the salary comes a responsibility to make the product you create conform to the "standards" that exist in whatever industry you are in, programming in this case. YOU don't own the product you are creating, or at the very least you are being paid to deliver a product to the client. They have the right to know that the guy that replaces you when you have stepped in front of the moving bus isn't rewriting a pile of "I'll do it my way 'cause I think the rest of the world is stupid". There is plenty of room for innovation and art in programming, you really don't need to trash conventions to prove anything. Doing things the right way can be a reward in itself as you become a world class programmer. 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 DWUTKA at marlow.com Sent: Tuesday, May 17, 2005 11:23 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Global Variable Well, I will meet you on the 'when there is a valid reason for doing so' part. As for the used sparingly, well, I think that is not quite right. You should dimension variables based on their scope. Global variables are one of three scopes. If you need a Global variable, then dimension it. If your app is overloaded with Global variables, if that is what you need, it is what you need. If you are not saying that they 'go away' as an argument, why do you consider them 'bad practice' still? Drew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Monday, May 16, 2005 5:33 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Global Variable Drew, I have a library (C2DbFW3G) that I use for all of my global code. There are thousands of lines of code, dozens of classes, hundreds of functions and NO global variables. They are completely unnecessary and no code outside of the framework itself has any business directly setting variables in the framework. I have plenty of private variables, initialized by the framework as it starts up, and I have a handful of functions that return the values in the private variables in the framework, but the variables themselves are not directly settable. Even from inside the framework, there are NO global variables. In my applications, I have a handful of global variables. I use them where they are absolutely needed, and there are a handful of places in my app where that is true. I do NOT use them as a convenience to avoid programming. I do not use them to make something faster without knowing that the speed increase is critical. Excuses like "they speed up the app" are just that, excuses. Speed is not the end all and be all of an application and speeding up something that is not a bottleneck at the expense of poor programming practices is not a good reason to use a global. The statement I made was "don't get carried away with them, they are considered bad practice in general". There is nothing about that statement that is wrong. They are considered bad practice "in general". They should be used sparingly. Every tool has a purpose, and global variables exist, therefore they must have a purpose. I did not make any statement that global variables should never be used, I simply said "don't get carried away with them". BTW I do NOT use "they go away" as a reason for not using them. In my estimation there should be no unhandled errors. The error handler insertion wizard that I co-wrote will assist the developer in getting an error handler in every single function in the project if that is necessary. There ARE valid reasons for using a global, but they are few and far between. There ARE valid reasons not to use global variables, many of them, all related to avoiding and finding bugs. If there were not valid reasons for not using them, then you would not have scope for variables. Your opening sentence seems to imply that there is no good reason not to use them and that simply is not true. Let's meet in the middle and agree that Globals should be used sparingly and only when there is a valid reason for doing so. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com