InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 22 May 2013 14:18:10 GMT20http://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxA while back, a long while back, I worked, in Japan, with a big Japanese company on the design and production of a computer. Although the manager had spent ten years in the states, the engineers spoke very little english and I spoke no Japanese. When it got down to team-work, it didn't prove too much of a problem because all the code was in assembler written in english, and we 'spoke in assembly language' together (to quote their manager). I've since seen a lot of Japanese and Iranian code and it is all in perfect english, even the comments (although the latter may no longer be the case... that was five years ago and unicode ins now more common.). The problems come with getting the Collation right for the target language, but you always have to keep the computer language and the language of the application/culture as separate issues. Confuse them at your peril!Wed, 09 Jul 2008 06:21:20 GMTPhil Factorhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxIn that case, I'm amazed at how many different peoples have apparently adopted the Arabic language as their own... just look at their code :PWed, 09 Jul 2008 05:17:25 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxOff-topic, but something I always wondered about:How do people who use the Arabic version of Windows manage to write C/C++/C# code? After all Arabic does not [i]have[/i] capitals.Wed, 09 Jul 2008 02:46:53 GMTmosaic-263591http://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote]Most of the time, we're perfectly happy with case-insensitive, accent-insensitive searches. The difference between upper and lower case (Majuscule and Minuscule) in the European languages are more accurately described as text transformations and they do not change the meaning of the word. C#r says that 'many European languages have multiple lower case letters that map to the same upper case one and vice versa'. This has sent me scurrying to the text books but all I can find is the German ß, which classically has no upper-case equivalent, but which is actually a ligature ( the two characters 'is'). The accenting of characters is again a modification or transformation as well. I'd be fascinated to know the details, but it doesn't affect ordinary commercial applications in Europe much. Even if it did, SQL Server as it exists can cope. (please would someone correct me on this!)[/quote]Only because you asked to be corrected, otherwise I'd let this go.As I've already stated in a prior post, German words can change between verbs (lower case) and nouns or gerunds (upper case, as all nouns are capitalized in German). So, for example, kommen is the verb to come--Wann kommen Sie/kommst du nach Hause? When are you coming home?. Capitalized, it takes a different meaning--Danke fuer das Kommen. Thanks for coming. The German ß actually represents a lower case 'ss', not 'is'. When the word is all caps, it is properly, but not always, spelled 'SS', especially with street (Straße) signs.Again, I'm not sure it's germain to the topic, and I only discuss it to clarify points that others have raised with regard to German. I'd be interested to know what Frank Kalis or some of the other Germans think of this discussion, as the upper/lower case rules in German have a lot of differences compared to English. It would be interesting to know if language colors our view of the topic.Tue, 20 May 2008 11:10:42 GMTRonKylehttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxPhil, see the annotated RFC for XML, explains it quite succinctly.Mon, 19 May 2008 10:15:18 GMTC#rhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxIn these postings on this forum, there have been quite a bit of confusion between the case-sensitivity of computer languages themselves and the various functions used for searching text.The proponents of case-insensitivity often seem to arge with the assumption that SQL Server has no existing way to deal with other languages than the western European ones. SQL Server already allows a wide range of collations. It is essential for dealing with other languages. This is far more advanced than just making string functions accent-insensitive and case-insensitive. Thanks from the advice from Java and C# freaks but you are trying to solve a problem we haven't got.Most of the time, we're perfectly happy with case-insensitive, accent-insensitive searches. The difference between upper and lower case (Majuscule and Minuscule) in the European languages are more accurately described as text transformations and they do not change the meaning of the word. C#r says that 'many European languages have multiple lower case letters that map to the same upper case one and vice versa'. This has sent me scurrying to the text books but all I can find is the German ß, which classically has no upper-case equivalent, but which is actually a ligature ( the two characters 'is'). The accenting of characters is again a modification or transformation as well. I'd be fascinated to know the details, but it doesn't affect ordinary commercial applications in Europe much. Even if it did, SQL Server as it exists can cope. (please would someone correct me on this!)Whatever the ins and outs of text manipulations, nobody in this forum has succeed in justifying the superiority of case-sensitivity in the symbols and tokens of computer languages. This would mean that one could create a perfectly legal statement such as Select sElect, seLect, selEct from seleCt. One can argue that modern IDEs can assist with this, but then all that means is that IDEs can cover up, or make up for, a very simple mistake- making the language itself case sensitive. There is simply no justification for imposing this on us.I'd be overjoyed to have it explained to me succinctly, in unemotional language, why allowing separate symbols spelled the same way but with different capitalisation should be better than having their existence flagged as an error, but in the meantime it makes no sense to me at all. I'm particularly interested in knowing why case-insensitivity in string functions should be better than being able to apply collations that are appropriate to the language, culture, and data being used.Mon, 19 May 2008 05:14:28 GMTPhil Factorhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]Anirban Paul (5/14/2008)[/b][hr]Readability comes from indentation and usage of space not from smaller case or capital case. [/quote]Just for the record, I strongly disagree with that and that's why I also say that case-sensitivity should be an option, not a mandate.Sun, 18 May 2008 17:40:13 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxIt's interesting that you say "The minority are forcing a change on the majority."Perhaps you are blithely unaware that over 75% of the world's population has no concept of "case sensitivity" because there is no such concept in Chinese, etc. For many of the languages that do support case-sensitivity there are big problems "assuming the computer can do it for me"; e.g. ToLowerCase(ToUpperCase(x)) doesn't always equal x even if IsLowerCase(x) is true. This is because many European languages have multiple lower case letters that map to the same upper case one and vice versa.It's only our completely narrow US (or maybe somewhat European) viewpoint that ever lets us think case-sensitivity is "normal"... it actually a ridiculous accident of a very small minority!You might want to be informed before "poo poo" folks (like the XML committee) who accurately documented [i]why[/i] they chose to make XML case sensitive. I can't speak to why K&R first choose case-sensitivity, and I certainly agree it can be a pain, but it is way, way better than repeating the mess the US made out of DNS (and the painful retrofits now going on with IRIs).If you want to slam anyone, it's the tools/IDE vendors who have locked some languages (can you say SQL) in a world of "visual notepad" instead of providing good feedback and strong typing that eliminates the errors you complain about.Sun, 18 May 2008 11:38:45 GMTC#rhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]Anirban Paul (5/14/2008)[/b][hr]Readability comes from indentation and usage of space not from smaller case or capital case. [/quote]Agreed that whitespace is step one, consistent case is almost as important to readability. We need both.Discipline is the key word.Wed, 14 May 2008 19:52:36 GMTCypherOzhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxAs I wrote, just my opinion...Wed, 14 May 2008 02:48:48 GMTthierry.vandurmehttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]thierry.vandurme (5/14/2008)[/b][hr]Haven't read all items, just wanted to share my opinion.Been programming C, C++, c# for 15 years or so (Hungarian notation, Camel case, ...). Big fan of tidy and well documented code. Coding SQL stuff in case-sensitive mode as well because I think it's more readable. The fact that my colleagues "praised" me for it a few months ago when they needed to takeover some stuff is proof enough for me. Discipline is the word you're looking for...[/quote]Readability comes from indentation and usage of space not from smaller case or capital case. Another point which is not digestable is how can small case brings discipline. With both cases you can write 'tidy and well documented code'. Isn't it?Wed, 14 May 2008 02:36:07 GMTAnipaulhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxHaven't read all items, just wanted to share my opinion.Been programming C, C++, c# for 15 years or so (Hungarian notation, Camel case, ...). Big fan of tidy and well documented code. Coding SQL stuff in case-sensitive mode as well because I think it's more readable. The fact that my colleagues "praised" me for it a few months ago when they needed to takeover some stuff is proof enough for me. Discipline is the word you're looking for...Wed, 14 May 2008 01:17:34 GMTthierry.vandurmehttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxBut is Sun, Microsoft listening about the case sensitiveness??? I doubt????:)Tue, 13 May 2008 22:01:03 GMTAnipaulhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]Ryan Clare (5/13/2008)[/b][hr]Talk about a holy war.CaseSensitivity ++;[/quote]No kidding :) I wouldn't have thought something like this could get people so worked up. I guess you never know what's going to get people riled :)Tue, 13 May 2008 19:17:48 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxTalk about a holy war.CaseSensitivity ++;Tue, 13 May 2008 13:25:50 GMTRyan Clarehttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]webooth (5/13/2008)[/b][hr]Then you could not do this,//Normal strings.stringbuilder stbTest = new stringbuilder();//Really BIG strings.STRINGBUILDER stbTest = new STRINGBUILDER();and don't even get me started on upper case numbers. :hehe:[/quote]Even better:[font="Arial"]StringBuilder SiTest = new StringBuilder();StringBuilder SITest = new StringBuilder();StringBuilder SlTest = new StringBuilder();StringBuilder SLTest = new StringBuilder();[/font]Tue, 13 May 2008 08:07:08 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]PhilM99 (5/12/2008)[/b][hr]I've read all the comments, and can't find one reason in the world why anyone would permit two [u]different[/u] objects to have the same name (visually and verbally) with only the minor exception that somewhere a letter has a different case.If one started out to define an annoying, error prone, time-wasting characteristic of a programming language it would be harder to find a better one.[/quote]Then you could not do this,//Normal strings.stringbuilder stbTest = new stringbuilder();//Really BIG strings.STRINGBUILDER stbTest = new STRINGBUILDER();and don't even get me started on upper case numbers. :hehe:Tue, 13 May 2008 06:28:21 GMTweboothhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxSSC Eights! I was not upset. I should have know than to get into a discussion about language. ;) I too have grumbled about case-sensitive and other things, but have learned, and sometime the hard way, that consistency and standards are very important to the long term life of software. If the language or the compiler and assist, force, or encourage consistency and other good things, that is a big help.Researching some of the new languages that are emerging, I have noticed a trend toward focusing on testing, maintainability, and quality in the language itself. I think this is a step in the right direction, and look forward to the next great language.Still there is a place for the less discipled language tools, and I would not want to discourage the appropriate use of those.Tue, 13 May 2008 05:34:29 GMTWyatt Eurichhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]kym.farnik (5/12/2008)[/b][hr]Then came *nix. To save memory and cpu (case conversion and matching) everything was case sensitive (filename, programming languages etc.). [/quote]LOL when I started reading this I was reminded of a student in one of my C.S. classes (has it been that long??) who proclaimed the following formula:lowercase characters = half-height characters = less memory per characterHe switched his major to English Lit. the next day. Thanks for the fond memory lolMon, 12 May 2008 19:35:30 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxHistory. I started programming in 1971... On an IBM 1130 then a System 370/115 - what is this lowercase you speak of? :)We only had uppercase. Ditto CDC Cyber 173 (NOS) and ICL 1900t (George III).Then came *nix. To save memory and cpu (case conversion and matching) everything was case sensitive (filename, programming languages etc.). CPU and memory were is short supply (Mhz and kbytes).Forward 30 years... HTML case insensitive tags, XML/XHTML case sensitive. Who knows?Domain names: Insenstive, the URI path: Depends on server OS. etc.Personally it does not bother me either way. But we must move towards a common and consistent way of naming.It looks like the case sensitive people will probably win in which case (ignore the pun) get used to it.Mon, 12 May 2008 18:49:37 GMTCypherOzhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxThanks to Mike C. for the MS Connect items. Amen!Mon, 12 May 2008 16:44:59 GMTJJ Bhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]GSquared (5/12/2008)[/b][hr]In almost all cases, artificial limitations (like case-sensitivity), have much higher lost-opportunity costs, than they have hard-costs. Flexibility gives more opportunities.[/quote]Just to add to what GSquared said, of course code like this will throw an exception:[font="Arial"]l = 1;l = l + I;printf("%i", I);[/font]But what really costs you is code like this that could be logically wrong, but doesn't throw an exception:[font="Arial"]l = 1;I = 2;l = l + I;printf("%i", I);[/font]Mon, 12 May 2008 15:15:42 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]troyehall (5/12/2008)[/b][hr][quote][b]GSquared (5/12/2008)[/b][hr]Surely your original example, where "ActiveWhatever" is an object and "activeWhatever" is a variable from that object, isn't enough to justify the effort expended by coders having to deal with an effort which is, essentially, alien to the way the human eye and brain work. Yes, the eye and brain can be trained to deal with it, and to catch it with tremendous skill, but at what cost? Could not the years spent becoming proficient with this be better spent on mastering more important aspects of coding? I would much rather have a developer spend time on learning how to write faster, less error-prone code, that gets more done in less time, and have that developer write "ActiveWhatever" for the object, and, for example, "ActiveWhatever_variable", as the variable name.Always, for me, it comes down to cost vs benefit. I've read the arguments in favor of case-sensitivity, but they always come down to very small benefits for very high costs. I just don't like to invest that way.Can you clarify that point for me? I'm willing to be convinced, but I haven't been yet.[/quote][p]For me the cost is whatever the license fees are for Visual Studio, the C# compiler and ReSharper. Visual Studio colors my code and gives me wavy lines (just like a word processor) so I can spot errors early. The compiler lets me know just a little bit later if it cannot recognize a given identifier. ReSharper also lets me know early, and gives me quick and easy ways to correct things that do not depend upon my typing skills. The other costs are developing rigourous naming standards and sticking to them for as many cases as I can without making the code less difficult to understand. However, these are simple to understand and implement. Also, when I can't refactor existing code, I use a lot of copy and paste, to save on typing and to minimize mistakes. Good habits and good tools reduce errors up-front, and reduce the costs of fixing those errors down the road. If I did not have case sensitivity, some of the things I copy and paste would require more code changes than simply retyping the first letter. To me, the semantics expressed by letter case are clear and concise.[/p][p]To sum up, the costs are licenses and developing good habits, and the benefits are improved productivity and consistency (=maintainability).[/p][/quote]We're not defining "costs" the same way.You list the financial price of the development environment that you're using. That's a non-variable cost. You'd pay it regardless of whether the compiler were case-sensitive or not.There are other costs:What happens when you copy-and-paste code, and fix 24 of the 25 instances of "ActiveWhatever" to "activeWhatever"? You have to spend the time searching for that string, deciding in each case whether it is an object or a variable from that object, and then fixing the ones that are variables where they should be objects and vice versa. Then, you have to attempt to build and compile the code. Then you have to go back into it, and redo the search from the top to find out which one you missed and why.You have to limit yourself on which developers you can hire (per your own statements about some people being constitutionally incapable of dealing with this). If a potential hire is brilliant at designing code, fun to work with, undemanding, has a great work ethic, and is otherwise an ideal employee/co-worker, but simply cannot visual pick out case differences easily, you have to either identify this during the hiring process (a cost) or fire the person after hiring (a bigger cost). Either way, you end up with the cost of "lost opportunities" that a case-insensitive compiler and language would give you with such a person.If you are the only person who will ever touch the software, you don't have this cost, but what costs are associated with having junior programmers who "just can't see the caps differences", whose code you have to go back in and fix after it's written?Those are MUCH bigger costs than the price tag on the dev studio.Game theory, which is what Return on Investment is based on, demands that you not just look at the options you have, but also look at the options you [i]could[/i] have if you change your parameters in possible ways.In almost all cases, artificial limitations (like case-sensitivity), have much higher lost-opportunity costs, than they have hard-costs. Flexibility gives more opportunities.Mon, 12 May 2008 14:58:47 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote]As for the comment about European languages not having a semantic difference between upper and lower case letters... in German the noun is always capitalized... I don't know enough German vocabulary to know if there are nouns that are the same as verbs, but certainly you could tell by looking at a German sentence which word was the noun.[/quote]Not really germain to the topic (I don't think), but in general German verbs that don't have an obvious noun match become nouns (of sorts--I think gerund is the correct term) when capitalized, with a definite article in the dative case. tanzen=to dance; das Tanzen=dancing; rauchen=to smoke, das Rauchen=smoking. The capitalization, regardless where it occurs in the sentence since, as mentioned, all German nouns are capitalized.Again, not particularly relevant to programming languages, but even before getting to the above quote the same thought had occured to me. We may approach the issue differently at least in part because we have few similar examples in English.Mon, 12 May 2008 14:50:00 GMTRonKylehttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]GSquared (5/12/2008)[/b][hr]Surely your original example, where "ActiveWhatever" is an object and "activeWhatever" is a variable from that object, isn't enough to justify the effort expended by coders having to deal with an effort which is, essentially, alien to the way the human eye and brain work. Yes, the eye and brain can be trained to deal with it, and to catch it with tremendous skill, but at what cost? Could not the years spent becoming proficient with this be better spent on mastering more important aspects of coding? I would much rather have a developer spend time on learning how to write faster, less error-prone code, that gets more done in less time, and have that developer write "ActiveWhatever" for the object, and, for example, "ActiveWhatever_variable", as the variable name.Always, for me, it comes down to cost vs benefit. I've read the arguments in favor of case-sensitivity, but they always come down to very small benefits for very high costs. I just don't like to invest that way.Can you clarify that point for me? I'm willing to be convinced, but I haven't been yet.[/quote][p]For me the cost is whatever the license fees are for Visual Studio, the C# compiler and ReSharper. Visual Studio colors my code and gives me wavy lines (just like a word processor) so I can spot errors early. The compiler lets me know just a little bit later if it cannot recognize a given identifier. ReSharper also lets me know early, and gives me quick and easy ways to correct things that do not depend upon my typing skills. The other costs are developing rigourous naming standards and sticking to them for as many cases as I can without making the code less difficult to understand. However, these are simple to understand and implement. Also, when I can't refactor existing code, I use a lot of copy and paste, to save on typing and to minimize mistakes. Good habits and good tools reduce errors up-front, and reduce the costs of fixing those errors down the road. If I did not have case sensitivity, some of the things I copy and paste would require more code changes than simply retyping the first letter. To me, the semantics expressed by letter case are clear and concise.[/p][p]To sum up, the costs are licenses and developing good habits, and the benefits are improved productivity and consistency (=maintainability).[/p]Mon, 12 May 2008 14:22:54 GMTtroyehallhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]troyehall (5/10/2008)[/b][hr]Phil Factor,Being able to easily spot the difference between [b]getElementById()[/b] from [b]getElementByID()[/b] while skimming through code is not a matter of being clever. In fact, I expressly stated that I do not think that it is a matter of being clever, smart or "good" at all. Some people just don't pick up or care about subtle differences in typed language, and my personal observations indicate that these same people have equal disinterest in correct spelling and punctuation of human languages. But regardless of their aptitudes in perceiving deviations from spelling and punctuation standards used by the people to and for whom they write, there is absolutely no reason to think that the semantic content of their communication is any less valuable or full because of it.My point is not to insult anyone as being less capable or intelligent in a general sense, but to point out that the flexibility afforded by case sensitivity is valuable and useful to a large number of people, and should not be taken away just because some other people find it inconvenient. To echo your comparison with certain African languages that use clicks, if you have difficulty understanding the language because of that feature, the solution isn't to ask the speakers to use English.Of course, abuse of the flexibility afforded by case sensitivity could lead to chaos. The same could be true of enabling people to name things using more than two letters. Any system is potentially abused, and will be. I agree wholeheartedly that "[i]The problem comes when you ... get the case wrong.[/i]." This is precisely why we (a) have standards and (b) don't go off and do something that violates them. I'll build upon my analogy as well: just because you have a handgun doesn't give you a right to shoot somebody with it; if you have trouble keeping yourself from shooting at people and property, you should be held accountable from the problems you cause with the gun; in the latter case, you probably should not be allowed near a gun to begin with.The "MyTableID" vs. "MyTableid" argument strikes me as a strawman supported by a lot of "ifs", "untils" and slippery slopes. Here is my own set of "ifs", "untils": [i]if[/i] you approach all coding as if it were impacted by case sensitivity, and use a consistent set of standards, you will not have to worry about case sensitivity. However, [i]until[/i] you approach coding with standards that include letter-case, you will be subject to the sorts of issues you mention, such as someone changing willy-nilly the collation.Sincerely,Troy[/quote]I'm a bit late to this thread and feel a little nit-picky with my response... but Troy in his post makes the case crystal clear. His own quote of "MyTableID" vs. "MyTableid" picked the wrong variation used in previous posts. It's so hard to differentiate that even the most adamant promoter of case sensitivity picked a new variation in his example. The second variation WAS "MyTableId" not "MyTableid".Probably exactly how Javascript ended up with two versions of getElementById/ID.As for the "Senior" pre-Bill guys out there who speak of precision and professionalism... they probably don't spend as much time as the rest of us do, trying to debug Jr. programmer's mistakes where case sensitivity is a nightmare to find.~LaneMon, 12 May 2008 13:57:19 GMTlane sandnesshttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]troyehall (5/12/2008)[/b][hr][quote][b]GSquared (5/12/2008)[/b][hr]Take a serious proofreading and copy editing aptitude test. I guarantee you will fail a number of the primary tests. Less than 1 person in 1000 passes the double-word test without training, less than 1% pass the tranpsosed letters test and, and less than 1 in 10,000 pass the missing parentheticals test. Which one of those did I include in this post? If you have to look back to find out, now that I've mentioned it, you fail the test. Did you pass it?)[/quote]In trying to show the fault in my logic, you have made my point for me. Only certain people are qualified to be proofreaders. If you can't catch the types of errors you are looking for, you should not be a proofreader, because you are neither naturally sensitive enough to detect issues like the "tranpsosed letters test" nor trained to be so. Of course, there are different degrees of proofreading proficiency, but the end goal of perfection is a constant. Proofreaders are not asked to change change that goal so that anybody can do their job. Programmers that work in case sensitive languages should not be asked to either. However, unlike proofreading, programming [i]does[/i] have positions for people who might not have the time, inclination or training to care about issues raised by case sensitivity. However, these people should be treated with the same respect as any other, and their tools (VB, SQL, SSIS, etc.) should not be changed to be case sensitive because someone that prefers it thinks it should be so. And the opposite is true as well.[/quote]Actually, having trained people (myself included) to proofread, who had zero "natural tallent" for it, I have to disagree with your basic thesis.As a proofreader, I am highly dependent on spellcheck. I am quite good at grammatical structure, vocabulary, punctuation, etc. I can almost always help someone clarify a point, whether it be a clause, book, or anything in between. And my spelling isn't horrible any more (was truly horrific when I was in school). Fortunately, the exact weaknesses I have in my spelling are things that spellcheck will consistently catch, and even with that crutch, my spelling is continuing to improve constantly.But I still have to ask, what benefit justifies the cost, when it comes to case-sensitive code? Surely your original example, where "ActiveWhatever" is an object and "activeWhatever" is a variable from that object, isn't enough to justify the effort expended by coders having to deal with an effort which is, essentially, alien to the way the human eye and brain work. Yes, the eye and brain can be trained to deal with it, and to catch it with tremendous skill, but at what cost? Could not the years spent becoming proficient with this be better spent on mastering more important aspects of coding? I would much rather have a developer spend time on learning how to write faster, less error-prone code, that gets more done in less time, and have that developer write "ActiveWhatever" for the object, and, for example, "ActiveWhatever_variable", as the variable name.Always, for me, it comes down to cost vs benefit. I've read the arguments in favor of case-sensitivity, but they always come down to very small benefits for very high costs. I just don't like to invest that way.Can you clarify that point for me? I'm willing to be convinced, but I haven't been yet.Mon, 12 May 2008 12:53:40 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]troyehall (5/12/2008)[/b][hr][p]I would add that personal preference of your employer or manager may not be a factor in your preference, but it may be a factor in your employment situation. If you get paid to use standards that leverage case sensitivity, you had better prefer a paycheck over your personal preference.[/p][/quote]I was actually considering adding organizational standards as a factor, but that's not really "personal" preference. I have my own personal preference for various programming languages, but I very often have to write code using other languages for a paycheck. The fact that an employer forces me to use Java doesn't really make it my "personal" preference.Mon, 12 May 2008 11:04:48 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]Mike C (5/12/2008)[/b][hr]I also think that personal preference is a bigger factor than # years of experience in general when deciding whether you prefer case-sensitive languages or case-insensitive.[/quote][p]I would add that personal preference of your employer or manager may not be a factor in your preference, but it may be a factor in your employment situation. If you get paid to use standards that leverage case sensitivity, you had better prefer a paycheck over your personal preference.[/p]Mon, 12 May 2008 10:48:50 GMTtroyehallhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]GSquared (5/12/2008)[/b][hr]Take a serious proofreading and copy editing aptitude test. I guarantee you will fail a number of the primary tests. Less than 1 person in 1000 passes the double-word test without training, less than 1% pass the tranpsosed letters test and, and less than 1 in 10,000 pass the missing parentheticals test. Which one of those did I include in this post? If you have to look back to find out, now that I've mentioned it, you fail the test. Did you pass it?)[/quote]In trying to show the fault in my logic, you have made my point for me. Only certain people are qualified to be proofreaders. If you can't catch the types of errors you are looking for, you should not be a proofreader, because you are neither naturally sensitive enough to detect issues like the "tranpsosed letters test" nor trained to be so. Of course, there are different degrees of proofreading proficiency, but the end goal of perfection is a constant. Proofreaders are not asked to change change that goal so that anybody can do their job. Programmers that work in case sensitive languages should not be asked to either. However, unlike proofreading, programming [i]does[/i] have positions for people who might not have the time, inclination or training to care about issues raised by case sensitivity. However, these people should be treated with the same respect as any other, and their tools (VB, SQL, SSIS, etc.) should not be changed to be case sensitive because someone that prefers it thinks it should be so. And the opposite is true as well.Mon, 12 May 2008 10:37:51 GMTtroyehallhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]Wyatt Eurich (5/12/2008)[/b][hr]I really should have not made that observation of the post so far. I should have known that that would catch ire. My apologies.I would like to say that in small bit of code and projects case sensitive does not seem to matter. Much larger projects with multiple developers, is a very different case.I have seen too many times, code that should not have worked but seemingly did because of case-insensitivity and scoping issues got into production.Sure, better testing, code reviews, and other tools should reduce that from happening, but I have to believe sloppiness begets sloppiness. Case-sensitivity would have helped those. Languages that ignore case seem to allow other sloppiness. SQL is not one of those, thankfully.[/quote]Wyatt - I'm not upset, and I hope I didn't give that impression. I just think the quality of the support tools (IDE, autosuggest, error highlighting, debugger, etc.) is what actually provides a lot of the benefits that people are associating with case sensitivity in a computer language. I also think that personal preference is a bigger factor than # years of experience in general when deciding whether you prefer case-sensitive languages or case-insensitive.======================Two wrongs don't make a right. But three lefts do.Mon, 12 May 2008 09:51:37 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxThere's only 1 thing in programming of ANY kind that SHOULD be case sensitive, and that is the values being passed by your parameters, be they password values, form labels, or other user data.Anything else should be modernized for the benefit of everyone. Simpler, faster, better.You want to use all caps? Fine.You want to use Camel text? Fine.Your choice of IDE should store it all as whatever and convert to your preference on the fly, and the compilers and languages should be updated to eliminate the difference. The whole reason we all aren't programming by binary on punch cards anymore is that someone found a simpler, cheaper, faster, better way to do it. Eliminate case sensitivity and you give up very little for worthwhile advances in simplicity.Mon, 12 May 2008 09:50:59 GMTmaloneykhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]GSquared (5/12/2008)[/b][hr]Take a serious proofreading and copy editing aptitude test. I guarantee you will fail a number of the primary tests. Less than 1 person in 1000 passes the double-word test without training, less than 1% pass the tranpsosed letters test and, and less than 1 in 10,000 pass the missing parentheticals test. Which one of those did I include in this post? If you have to look back to find out, now that I've mentioned it, you fail the test. Did you pass it?)[/quote]I caught the missing open parenthesis and the double "and, and" on the first pass. I missed the tranpsosed letters on the first pass, but I assume that's because I didn't know I was being tested :) Presumably when you sit down to take these tests you know in advance you're being tested? Or do they really perform these tests surreptitiously?===================Two wrongs don't make a right. But three lefts do.Mon, 12 May 2008 09:42:03 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]troyehall (5/10/2008)[/b]...This is about about choice. ...[/quote]You just failed your own proof of observation of language. :)Thus, per your own argument, you need to stop stop using case sensitivity. :)Mon, 12 May 2008 09:16:44 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]troyehall (5/10/2008)[/b][hr]Phil Factor,Being able to easily spot the difference between [b]getElementById()[/b] from [b]getElementByID()[/b] while skimming through code is not a matter of being clever. In fact, I expressly stated that I do not think that it is a matter of being clever, smart or "good" at all. Some people just don't pick up or care about subtle differences in typed language, and my personal observations indicate that these same people have equal disinterest in correct spelling and punctuation of human languages. But regardless of their aptitudes in perceiving deviations from spelling and punctuation standards used by the people to and for whom they write, there is absolutely no reason to think that the semantic content of their communication is any less valuable or full because of it.My point is not to insult anyone as being less capable or intelligent in a general sense, but to point out that the flexibility afforded by case sensitivity is valuable and useful to a large number of people, and should not be taken away just because some other people find it inconvenient. To echo your comparison with certain African languages that use clicks, if you have difficulty understanding the language because of that feature, the solution isn't to ask the speakers to use English.Of course, abuse of the flexibility afforded by case sensitivity could lead to chaos. The same could be true of enabling people to name things using more than two letters. Any system is potentially abused, and will be. I agree wholeheartedly that "[i]The problem comes when you ... get the case wrong.[/i]." This is precisely why we (a) have standards and (b) don't go off and do something that violates them. I'll build upon my analogy as well: just because you have a handgun doesn't give you a right to shoot somebody with it; if you have trouble keeping yourself from shooting at people and property, you should be held accountable from the problems you cause with the gun; in the latter case, you probably should not be allowed near a gun to begin with.The "MyTableID" vs. "MyTableid" argument strikes me as a strawman supported by a lot of "ifs", "untils" and slippery slopes. Here is my own set of "ifs", "untils": [i]if[/i] you approach all coding as if it were impacted by case sensitivity, and use a consistent set of standards, you will not have to worry about case sensitivity. However, [i]until[/i] you approach coding with standards that include letter-case, you will be subject to the sorts of issues you mention, such as someone changing willy-nilly the collation.Sincerely,Troy[/quote]I spent 7 years as the manager of an editing, typesetting and proofreading office. Your statement about "...these same people have equal disinterest in correct spelling and punctuation of human languages...." is provably false as a premise for this argument.Take a serious proofreading and copy editing aptitude test. I guarantee you will fail a number of the primary tests. Less than 1 person in 1000 passes the double-word test without training, less than 1% pass the tranpsosed letters test and, and less than 1 in 10,000 pass the missing parentheticals test. Which one of those did I include in this post? If you have to look back to find out, now that I've mentioned it, you fail the test. Did you pass it?)The problem with broad, sweeping statements about things like this, is that they are, essentially, opinions, unless they can be backed up with facts, figures, etc.So, claiming that case-sensitivity improves functionality, don't make statements about people's inability to deal with it as a shortcoming (disparaging or not), unless you can prove that it actually has a benefit with an actual return-on-investment. Does it improve coding speed? Quality? Functionality? Does it make it easier to debug/refactor in such as way as to improve profitability? If it doesn't improve profitability, then you must be arguing that it improves the end-user experience. Does it? If not, then it has no validity in an engineering discipline.If the benefit isn't an engineering one, then it must be aesthetic. Do more people admire the code because of it?So, which engineering benefit does it actually generate, and by how much? (If you can't measure it, it's not engineering.)Mon, 12 May 2008 09:13:00 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspxI really should have not made that observation of the post so far. I should have known that that would catch ire. My apologies.I would like to say that in small bit of code and projects case sensitive does not seem to matter. Much larger projects with multiple developers, is a very different case.I have seen too many times, code that should not have worked but seemingly did because of case-insensitivity and scoping issues got into production.Sure, better testing, code reviews, and other tools should reduce that from happening, but I have to believe sloppiness begets sloppiness. Case-sensitivity would have helped those. Languages that ignore case seem to allow other sloppiness. SQL is not one of those, thankfully.Mon, 12 May 2008 08:46:09 GMTWyatt Eurichhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[p] A simple test to put in your build scripts or stored procedures. As far as I know, the only way to heal this problem if it happens is to reset the database_default collation, or is that the DATABASE_DEFAULT Collation?[/p][font="Courier New"][size="2"][color="black"][/color][color="blue"]IF  [/color][color="red"]'a' [/color][color="gray"]<> [/color][color="red"]'A' [/color][color="black"]collate database_default   [/color][color="blue"]BEGIN   RAISERROR [/color][color="gray"]([/color][color="red"]'Oh no! Your database is case-sensitive for keywords!'[/color][color="gray"],[/color][color="black"]16[/color][color="gray"],[/color][color="black"]1[/color][color="gray"])   [/color][color="green"]--return 1   [/color][color="blue"]END[/color][/size][/font]Mon, 12 May 2008 08:19:43 GMTPhil Factorhttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]PhilM99 (5/12/2008)[/b][hr]Well, lots of discussion anyway. My 2 cents is that those of us programming since way back in mainframe days still wonder why they added lower case to the keyboard anyway.[/quote]That's simple - they had to add lowercase letters so we could all program C, since all the C keywords are lowercase :) With that in mind, the question becomes why did they *keep* uppercase? :)=========================Two wrongs don't make a right. But three lefts do.Mon, 12 May 2008 07:56:12 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]Wyatt Eurich (5/12/2008)[/b][hr]I find that problems such as typo’s that occur in case-insensitive languages, harder to track down.I prefer a computer to do what I tell it to do, right or wrong, and I have more of a chance of that happening when I am working in a case-sensitive language.[/quote]I find that fewer typos occur in case-insensitive languages, although the number goes down significantly for both if you have a decent IDE with autocomplete features.[quote]I think having an option in a language to be case-sensitive or insensitive is not good. Consistency in language that needs to be precise is very valuable.It is interesting, after reading the posts, generally, those preferring case-insensitive language are those less experienced with coding.In my old age, I find I want a language that is precise, concise, and reduces errors. I feel case-sensitivity fulfills those requirements very well.[/quote]I think whether or not you "enjoy" case-sensitivity in your language of choice has more to do with personal preference than inexperience. I program a variety of languages, and case-sensitivity related issues are harder to track down in some languages than in others. I think that has more to do with the support tools available for writing code and debugging than anything else. As Phil points out, if you're writing case-sensitive XHTML in Notepad it's going to be a bit harder to locate errors caused by case-sensitivity than in an IDE with autocomplete and error highlighting.I also think this conversation has split into two separate paths (and that may be my fault). One path is case-sensitivity in an actual programming, scripting, markup, or query language; as in the variable names and keywords are case-sensitive. The other path is case sensitivity of data, as in the case-sensitive nature of SSIS Data Flow transformations which cause it to behave differently than equivalent SQL Server statements in a case-insensitive database. When you search for "SMITH" in a database, many expect that "Smith" and "smith" will be considered matches, but that's not the case in SSIS Data Flows, regardless of your database settings.As far as case-sensitivity in languages, I think it's based more in expediency for the language designers than any high-falutin' academic reasons. Take the case-sensitivity of XML, for instance. According to the editors of the XML recommendation one of the goals of XML was that any mid-level programmer (6+ months experience) should be able to implement an XML parser (their reference language was Perl, but I think it probably applies across programming languages). Since another goal of XML was internationalization, adding case-insensitivity would have meant that that same mid-level programmer would have to implement case-insensitive collation libraries to cover all the alphabets covered by Unicode in over 40+ different languages. That's probably beyond the ability of most programmers with less than a year of experience. Straight binary comparisons, however, are well within the ability of most programmers after a couple of days on the job.==============Two wrongs don't make a right. But three lefts do.Mon, 12 May 2008 07:50:12 GMTMike Chttp://www.sqlservercentral.com/Forums/Topic498304-34-1.aspx[quote][b]Wyatt Eurich (5/12/2008)[/b][hr]Having coded before Bill Gates and in 40+ languages like a previous poster, I prefer case-sensitivity.I find that problems such as typo’s that occur in case-insensitive languages, harder to track down.I prefer a computer to do what I tell it to do, right or wrong, and I have more of a chance of that happening when I am working in a case-sensitive language.I think having an option in a language to be case-sensitive or insensitive is not good. Consistency in language that needs to be precise is very valuable.It is interesting, after reading the posts, generally, those preferring case-insensitive language are those less experienced with coding.In my old age, I find I want a language that is precise, concise, and reduces errors. I feel case-sensitivity fulfills those requirements very well.I would not be opposed however if MS wanted to introduce a case-insensitive scripting language as an option.[/quote]Having tackled my share of languages in my paltry 20 years of experience, I have to say I see a difference between case insensitivity and chaos (must be my lack of experience talking). I certainly appreciate you feel more comfortable with case-sensitive, but with all due respect - neither side implicitly increases or decreases errors. Either one requires a discipline, a structure and some actual knowledge about how to approach the issue at hand. Case-sensitivity doesn't prevent you from writing crappy code, nor does case-insensitivity automatically mean you're a sloppy coder.Consistency is something I can definitely get on board with, but allowing case alone to differentiate between different objects is just a bad practice IMO. THAT allows the introduction of rather nasty bugs as well (was I calling the base class' method generically or the method on the instantiated object?), in my experience. It's also NOT something I'd want to be relying on at 3AM when the SQL server had a bad day (I am not that good of a typist for one thing, so UPDATE MyTable versus UPDATE MYTABLE while I'm trying to wake myself up on a call just plain isn't something I'd want to deal with). It's also a practice entirely forbidden in my organization ("no evil twins").Properly cased code is easier to read - just as is properly formatted, indented and commented code. It's however more in the realm of form than than it is substance: let's just not turn this into the Holy Grail for coding standards.Mon, 12 May 2008 07:49:50 GMTMatt Miller (#4)