"We can get in a client comparison war, but I was referring to now."
No thank you, I don't think who you, I or anyone else works for now or in the past has any bearing on coding knowledge or expertise. I already explained that many of the best coders I know develop small audience internal applications. "I think you are just lucky that they are not technical and have no idea what you are doing. When I hear things like when you're working for a company that bounces paychecks that upsets me. They do not have much cash, and the last thing they need is someone wasting their money. I just got upset at that, and I am sorry." I do not appreciate you inferring that I am wasting my employer's money. I'm not "tricking" them into writing their code correctly; even the suggestion is a little comical. (Oxymoron? *shrug* maybe) You have no idea how much this company has lost in client leverage and funds due to code that cannot be extended, cannot be easily maintained, and performs poorly. I share the same views as everyone in my office, that doing something right does not equal wasting money. (even if it requires extra keystrokes. *gasp*) "You wouldn't have job right now if it wasn't for my beginner style coding, that is what upsets me." That is just plain ridiculous Jacob. I'll be happy to forward you my resume if needed, but I hardly have you to thank for my career. In a way you might be correct though with this client... If it wasn't for the lack of good coding practices and code that is difficult to maintain, they could have hired someone will less experience and saved some money. "Nate believes that you should always scope. I disagree. Should you drill it in to newbees heads, sure. But calling me a beginner was a little uncalled for in my mind." This statement actually conflicts with itself. *chuckle* Drill it into newbies to scope so they will do it, but don't call those whom don't scope newbies? Huh? Besides, I wasn't calling you that in the first place, if you inspect the message you will see this. The statement was more along the lines of "Am I the only one that thinks scoping is a must and day one stuff?" - and said it before you took everything to a personal level, it wasn't even for your benefit. =) I am sorry if you took that personally, it was not intended to insult you. Again, I apologize if I did. "He called upon the list to prove me wrong." Again, I started the thread to discuss it. You were never mentioned. And if you are inferring that all the developers on the list would ultimately agree that scoping is best practice, maybe all of us aren't as crazy as you think. "In my mind, if you can't read someone's code, you don't really know that Language that well and you should read it, you will learn something." This is the most irresponsible thing you have said yet. Code poorly and leave a trail of dead clients in your wake and hide behind a "you don't really know that language that well", it's your business. It's just not worth arguing about. When your clients catch onto your mentality in that regard, the scolding from them will do a better job than anything I can say here. Jacob, after our conversation - I started this thread for myself. No one had any idea about you. I did not mention your name. I did not give examples of your code. Most importantly, I did not get ugly on a personal level with you, and still don't think I have. I talked about the subject in a general fashion to get opinions of others, not to start a flame war with you. This information was for a discussion for my own benefit and the benefit of others. You decided to make this a personal flame war, which was not my intention. If you want to talk about the issues that are not related to this discussion as intended or personal issues that will not benefit others on the list, please email me directly. I apologize to the list that this turned into a flame so quickly - I really didn't want it to. I do think scoping is an important topic still, and one that does need some light now and then. <cf_flame action="close"> I'll leave this thread to smolder for a while. =D Friday Friday Friday baby! Best Regards, Nate Nielsen [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacob Cameron Sent: Friday, September 19, 2003 8:59 AM To: [EMAIL PROTECTED] Subject: RE: Since its so quiet lately . . . Sorry, I did rant and make some bad statements you are correct. However, I started the IT department at the company you are at now in 2000. They had no servers, software, or development environments. You complained yesterday that enterprise manager took to long to load because of all the databases and I didn't use query., I used <cfoutput query. Come on, please. In the long run as many people have pointed out, it makes no difference. At one point there was a bug in CF 4.5 or 5, where if you used queryname.variable inside of double looped queries, the inner most query doesn't loop through the RS, that is the main reason I don't do scoping there. Then you come back because I don't do scoping in that one case and say that I said never to scope? That is how I took it. I do scope when it is needed or called for. You somehow thing it is a bug in my coding method to not use queryname.variable name, that is fine, but it is not in my opinion. We can get in a client comparison war, but I was referring to now. You are wasting money of the guys I used to work for by rewriting code that works fine just because you don't like the way it looks. I think you are just lucky that they are not technical and have no idea what you are doing. When I hear things like when your working for a company that bounces paychecks that upsets me. They do not have much cash, and the last thing they need is someone wasting their money. I just got upset at that, and I am sorry. I worked 60-80 hours a week. Meeting with perspective clients, bidding projects, and getting them done within budget. In my spare time setup an hosting environment of 7 servers to host it all and monitored it 24x7. Then someone comes along who the company can now afford to hire because of all my blood sweat and tears and complains that I didn't do it to his liking. Sure it works but not to his liking. It upsets me greatly. It I be coding wrong, sure, I learn new stuff everyday. Your last line of the first email of "Am I alone in thinking scoping variables is an absolute must, and pretty much day one stuff?" was very uncalled for and that is what set me off. You wouldn't have job right now if it wasn't for my beginner style coding, that is what upsets me. Jacob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nate Nielsen Sent: Friday, September 19, 2003 1:18 AM To: [EMAIL PROTECTED] Subject: Re: Since its so quiet lately . . . Jacob, I was honestly looking for objective views on the subject. Stop taking everything so personally and attacking people. BUT since you want to, and in response . . . *evil grin* <cf_soapbox> "Do any of the sites you have created or maintain get that many hits?" : Yes. =) "If I would do something as backwards as looping through an entire scope to reset one scope to another and claim it to be faster, who could possibly think that finding a work around to try and make your statement true would possibly be logical?" Write this down: <cfset request.form = structNew()><cfset request.form = structCopy(form)>. Not exactly looping over an entire scope, is it? Try not to prove your point with invalid or poor code theory, it reflects badly on yourself, not me. Regardless, I am of the belief that you can design an application without having to have access to both scopes as equal to make things "easier" on myself, you brought up the ideology of using them to accomplish the same - not me. Even if we decided that form and url "scoping is not a must." - I am of the belief that query scoping - is in fact, a "must" - which is an important point, because even those that my sway on the form and url issue, would likely believe that query scoping just plain makes sense. Your idea of outputting a variable : <cfoutput query="qMyQuery"> <cfset firstName = firstName> </cfoutput> <cfoutput> #firstName# </cfoutput> My idea of outputting a variable: <cfoutput> #qMyQuery.firstName# <cfoutput> I think in the above example, the statement <cfset firstName = firstName> says it all (a = a is plain ridiculous). First of all you are now creating a new memory space to duplicate effort. You have created a loop process to set the information, only to help CF understand what you are ~attempting~ to accomplish. You have required CF to search scopes 3 times, whereas mine did not search any. You are also making extra key strokes, which as you point out in your opinion, is an important consideration when coding. I cannot see any possible way for someone, or you, to defend that. *tongue in cheek* You work on a site that receives supposedly 2 million hits a day, which is boils down to closer to 200,000 page views per day, and last time I checked, that number is still a little inflated. One site though - big deal. You are seriously out of your league. To assume the only site I have worked on gets 1,000 hits per day or 1,000 a month "more like" is plain irresponsible on your part. On a personal note, my web work resume alone runs circles around yours (Coca-Cola,FedEx,American Airlines,The Sabre Group,Ernst & Young LLP,The Associates,GTE (Verizon now of course),AT&T,Nortel Networks,RealEstate.com,etc) so you might want to reconsider your position of "hits = knowledge" or you will win this argument for your opposing team real quick. Regardless- Some of the best developers I know work on internal applications, providing elegant solutions to complex business problems. I think it has no relation of ones knowledge in the matter. Bottom line is that : [1] scoping does effect performance. Having the server search for your variables for you, to save you typing a few letter is just plain lazy, or you just don't know any better (as we all didn't at one time of course). Yes, there are real-world impacts of this when you are dealing with values, not just looping over code a million times. If you have ever dealt with calling queries via structs and arrays, hefty query recursion with UDFs, used a complex stack storage method, used WDDX or XML for storage of scoped information, etc - you would know that 1ms per block of code can be the difference of 100s or 1000s of ms in the end. [2] scoping does effect code readability. The example of code above was taken from real-life, "production" code. When you reach a form that says value="#firstName#" - you have 6 pages for the request, plenty of queries (don't get me started,lol) - Where is the coder to look for the value of "firstName". Is it a value that was passed from a previous form submit? Is it a value that was set to a default? Is it a value passed in the URL? Is it a value from a query? Why should we suffer another developer to search for 5-10 minutes to save ourselves from typing "qMyQuery." in front of that value? I think a top priority and quantifiable value to a client is not only delivering code that squeezes every ounce of performance, reliability and function our of the serve - but also to keep one eye on extensibility. Wasting countless hours on re-coding or searching through spaghetti code is the most expensive risk that can be assessed because the ramifications are limitless. " In talking about speed, there is a lot more involved than scoping a variable." -I'll agree with you on that, but doesn't mean we shouldn't bother doing everything in our power to speed up our code - especially if we know better. That's like saying "you don't need to drink liquids, because more than that is involved in nutrition." Do we have to pick and choose to use our knowledge for only some things, when we know other are important as well? "And as many of you know, I also believe that if you say that you should 'always' do something in code, then you are very narrow minded." Try these: Always comment your code, even if it be minimal. Always try to use joins before resorting to looping over queries for information. Always name your variables with meaningful names (username rather than var038475). Etc. Is it really fair to say that general rules and guidelines can't be placed while mainting an open mind? I think you can have both. *gasp* My simple question was, and still is - is there any excuse rather than laziness or lack of knowledge (we should all admit we've all been there too) that anyone can give me for not scoping variables? I've never heard one, and thought maybe someone here might be able to enlighten me. =) Regards, Nate Nielsen (also, if you want to continue to attack people, you will continue being attacked yourself. please take it off list if you can't handle this subject objectively.) ----- Original Message ----- From: "Jacob Cameron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 6:27 PM Subject: RE: Since its so quiet lately . . . > As I said earlier today when I was talking to someone, I won't use any > names:) Sometimes you want to leave scope off of form and URL mainly > for their use. If they are referring to my code, they will notice > that there is always scoping used on CGI, Cookie, session and a lot of > other variables. Do I normally avoid them, yes when writing form > validation code > so I don't have to type as much. If I would do something as backwards > as looping through an entire scope to reset one scope to another and > claim it to be faster, who could possibly think that finding a work > around to try and > make your statement true would possibly be logical? > I didn't say there was anything wrong with scoping, simply that I > don't do it on form and URL normally unless I am doing it for security > reasons. > In my mind, scoping is not a must. A knowledge of its existence in > the world sure, but if I had my way. Everyone would start learning to code > with ANSI C so they learn about scoping from that as I did. > And as many of you know, I also believe that if you say that you > should 'always' do something in code, then you are very narrow minded. > Do you think allowing none scoped variables in CF and ASP was an > accident? A bug? Or are you just smarter than the creators of these > scripting languages? > Also, in the past I have created sites that have received over 1 > million hits in one hour and currently work on a site that receives > over 2 million hits a day. You work on sites that get 1000 hits a day > if they are > luck, more like 1000 a month. In my mind, worrying about this kind of stuff > is a waste of your time an your employers. Code anyway you want. I > code my > way, that I know works and have testing in live environments, not > looping on > beta code. If you want to code your way that is fine, we don't even > work together. > I cannot see the difference in load times from scoping or not scoping > url or form variables, so you are right because you think you are? > As you said this afternoon, you can loop through it 1 million times > and see > a difference. If you get 1 million hits in one second or less to a website > you created, you will run out of threads before a single web server > will be > able to serve it an everyone will be waiting in line anyway. In talking > about speed, there is a lot more involved than scoping a variable. Do any > of the sites you have created or maintain get that many hits? Are > they on a > single server or on multiple. Mine is on a single server running CF 5.0. > > Jacob > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of S.Isaac Dealey > Sent: Thursday, September 18, 2003 5:55 PM > To: [EMAIL PROTECTED] > Subject: Re: Since its so quiet lately . . . > > I was pretty slack about scoping variables when I first started > working with > ColdFusion and for a while I tried to leave form and url variables unscoped > intentionally, although I've given up that habbit. I like to copy all > my form and url variables into an attributes structure in the > application.cfm which allows me to use base templates as custom tags > if the need arises and > it's only 3 short, sweet lines of code. (It's one of the nicer tricks > from > Fusebox) If you use New Atlanta's BlueDragon server it's only 2 lines > of code because BlueDragon automatically combines the form and url > variables, so referencing form[var] is the same as referencing url[var]. > > I've mostly gotten out of the habbit of unscoped variables, and try > even with the variables scope to scope them because sometimes when you > don't scope them during a set statement they don't actually get into > the variables > scope, although I don't know how or why they don't. If I need a temp > variable quickly for a loop or the like, I'll frequently use a single > character variable like x or i unscoped, only if I know that I've set > it and > am making all references to it in the same template. And of course, if it's > in a function or a CFC method, I always make sure to use <var> to > declare the same single-character variables just in case. > > Is scoping one of the first things a cf developer should learn? Maybe. > I think so. I know the question of scoping has sparked minor flame > wars on the > cf-talk list. Not by any means like the flame wars sparked by the > issue of locking, but they've happened. > > > s. isaac dealey 972-490-6624 > > team macromedia volunteer > http://www.macromedia.com/go/team > > chief architect, tapestry cms http://products.turnkey.to > > onTap is open source http://www.turnkey.to/ontap > > > > Thought I would spark up a quick discussion. > > > I was discussing a few things with a coder (no names), and I raised > > the subject of scoping variables. > > > I am a real stickler when it comes to scoping variables. > > Other than obvious > > performance gain, and not having the issue of values bleeding from > > one scope into another - scoping simply makes code much easier to read. > > > Looking at the variable #customer# tells you there is a variable > > named customer. Looking at the variable #form.customer# or > > #qInvoice.customer# tells you where the value came from and some > > insight on how it is going to be used, why, etc... (Especially when > > you deal with more than one page per > > request) > > > I do on the other hand leave local scoped variables alone (the > > variables.[name] scope) - Which I think is standard practice, and > > there is no ambiguity when only one scope follows such a convention. > > > I was curious if anyone else had a differing view of scoping. > > Perhaps (though I highly doubt) someone can give me an example of > > when leaving off the scope of a variable name has an actual advantage. > > > The only idea that was half valid was using either form/url scope. > > This of course can be solved by coping one scope into the other and > > can be done in a few lines, so in the end, I don't think it's much > > of a valid point at all. > > > Am I alone in thinking scoping variables is an absolute must, and > > pretty much day one stuff? > > > Best Regards, > > > Nate Nielsen > > [EMAIL PROTECTED] > > > ----------------------------------------------- > > To post, send email to [EMAIL PROTECTED] To unsubscribe: > > Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / > > unsubscribe: http://www.dfwcfug.org > > > > > > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / > unsubscribe: http://www.dfwcfug.org > > > > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / > unsubscribe: http://www.dfwcfug.org > ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
