Kevin: I'm sorry to say, on this rare occasion I disagree with your assessment. First, anyone who learned to type has no problem with the [Shift] key being used. In fact, those who've learned to type often type words instead of letters so there is nothing "efficient" in saving the [Shift] keystroke; to be honest, it's usually a problem not to include the key as part of the overall typing framework. I often laugh when I see "C" code because I know it was designed by geeks who couldn't type and are, ultimately, two finger peckers. :-) To those who say they don't have time to learn how to type I say they have an "obligation" to learn to use the tools of their trade. Do accountants not know how to use a 10-Key? Do doctors not know how to use a stethoscope? Do carpenters not know how to use a plane? Of course they know how to use them! With that said, let's look at some of the major aggravations of this case issue. Most of us, not all but most, have multiple windows open when we work. We may have a web browser open, or an email client, a word processor, a spreadsheet, or other applications. All of these applications, and I mean "all" of them, expect [Caps Lock] to be off (in fact, so does Unix)! When we move our focus to a U2 window we have to turn that darned function back on. When we go back to one of the other applications we end up typing "cAPS lOCK" all the time. This is so true that even when we watch demonstrations, where U2 is in the mix, we see the demonstrator having the same problem over, and over, and over (like switching back to U2 from another window to enter a TCL command, then backspacing over the typed in command to change it to upper case). For those who spend the majority of their time in the U2 environment, [Caps Lock] is probably set to on. However, for most of the rest of us it's a colossal aggravation, over, and over, and over. U2 (UV much more than UD) has come up with some partial solutions to this casing issue (because they recognize the error of their ways but it's too much trouble to fix it). UD is tough at ECL because case makes a big difference in an ECL verb. Having an ECL shell processor that can upper-case all commands doesn't quite work in UD when one wants to use a lower case ECL verb. With case sensitivity, it's clear there is a difference between the variable CUSTOMER.REC and Customer.Rec. I'm not at all convinced those who've thought this through really would create one variable "CUSTOMER.REC" and another variable "Customer.Rec". Yet, again, upper-casing "forces" everyone to work around its serious limitations. The only place where I've found case to be important, other than in MV, is in command line options in Unix (here we run into those two finger geeks again). :-) Upper case is an anachronism and should be treated as such rather than defended. It is unwieldy for far too many and, in fact, interferes with efficient typing at every turn. Forcing people to use [Caps Lock] in U2 while all other used applications require [Caps Lock] to be off is a egalitarian ruse for autocracy. :-) This is, of course, IMHO... Bill
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: Saturday, March 08, 2008 9:39 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] blank lines in code / mixed case I am admittedly a dinosaur of the upper-case bent with U2. Before I put on my flame suit, hear me out.. We developers type thousands - possibly even millions - of characters of code per year To press the letter "R" with caps lock on or off is only one keypress - keeping in mind the state of the cApS LocK. To type READU then is only 5. ReadU however, is 7 - an increase of 40%. Now, assuming that a typical program is 4000 characters, there's a potential of an additional 1000+ shift keypresses just to maintain case. Meaningless, you say? Everything we do takes an investment of time, and even a fraction of a second can turn into a significant investment when multiplied times millions of occurrences. In Java, PHP, etc., mixed case code has been the norm from the beginning. People don't think about writing these languages in upper case because they were never designed to be written that way. BASIC, however has its roots in upper case, and - here's my big point - not being forced into mixed case provides a significant opportunity to produce more code in less time simply because of the reduced number of keystrokes. Also on the topic of productivity, a variable named ITEM.CUSTOMER has one presentation, no variants. Mixing case on this variable produces a number of variants which may be easily mistyped thus potentially increasing debugging time. I will admit, because I don't use mixed case I don't know if there's a compiler option that will allow ITEM.CUSTOMER and ItEm.CuStoMerto be the same variable, but even if such a thing exists, isn't that just adding confusion to whomever has to compile this thing six months from now? Those who have gone through my training have likely heard my rule about "there's a time and place for everything, and it's not always and it's not never". Anyone who "always" writes in mixed case regardless of the language or environment, or anyone who "never" writes in mixed case for the same reason may very well be missing productivity gains, regardless of how distasteful the caps lock key might be to them personally. Yes, I do use mixed case - in user prompts - because the audience (i.e. users) interprets meaning in the case of a message. And one last point to really fire up some folks: To those who think mixed case is more readable, I offer this: It's syntax, not literature. While we should do everything we can to make the code as human readable as possible, greater readability gains are available through structural protocol than changing READU to ReadU. To put so much energy in all these extra keystrokes and then to create a 3000 line routine with 1200 GOTOs (oops, I meant "GoTo"'s) is ... in my opinion... a lot of effort with minimal - if any - ROI. So, without turning this into a holy war, why do you prefer mixed case? -K ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
