• PinkyAndTheBrainFan187 (unregistered) in reply to frits
    frits:
    Me:
    frits:
    This is literally the lamest WTF that has ever been posted.

    Seriously, who hasn't had to do something like this?

    Me. I don't even understand what the coder is trying to do. Usually, the WTF has some kind of twisted logic, and I normally mentally translate unfamiliar code into one the coding languages I'm at least semi-familiar with, but this just doesn't make sense.

    So: global $EmailAddress (etc) produces a preassigned global variable? Which is then assigned to another global $email variable, which if false (or null?) results in another preassigned global variable, and so on? What's the point?

    If you can't figure this out, than your a moron. The email needs to get set from an ordered priority of places. The only thing is that they happen to be named similarly (except for case). Obviously, you could change the variable names elsewhere to this and it would be readible.

    if (!$email){
        global $primaryEmail; 
        $email=$primaryEmail; 
        if (!$email){ 
            global $secondaryEmail; 
            $email=$secondaryEmail;
            if (!$email){
                global $tertiaryEmail; 
                $email=$tertiaryEmail; 
                if (!$email){ 
                    global $email4; 
                    $email = $email4;
                    if (!$email){ 
                        global $email5; 
                        $email = $email5; 
                        if (!$email){ 
                            global $email6; 
                            $email = $email6; 
                        }
                    }
                }
            }
        }
    }
    

    Oh hi there frist! Err...yeah...TRWTF is calling someone a moron, pretending to be "smart" by using primary, secondary & tertiary as prefixes on your e-mail variables and then giving up and using numeral suffixes because you're too fucking stupid to know the words "quaternary", "quinary" and "senary".

    And all this in a comment on a WTF which boils down to stupidity and inconsistency in variable naming! Isn't it ironic? Don't ya think? You lovable little troll you! :x

    Captcha: ingenium (The irony of the troll was so ingenium I nearly plotzed).

  • Voo (unregistered)

    Actually there's a wonderful technical reason why case insensitivity just won't work in lots of modern languages.

    Unicode.

    Well that and the fact that there are valid programs out there that'd break, but back to the more interesting part. As soon as you allow unicode for variable characters (well I could live without it, so that would be an alternative) the conversion between lowercase and uppercase isn't unique any longer. In german for example the uppercase for ß is SS, so SS should be equivalent to ss as well as ß. Considering that unicode contains lots of languages, who all have their little quirks I'm pretty sure the whole undertaking will get quite fun to implement and confuse absolutely everyone.

  • Joops (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    wtf:
    Mason Wheeler:

    Case sensitivity was allowed on C, like so many of its other misfeatures, simply because it's easier to implement. Case sensitivity makes for simpler string comparisons and you don't have to store both original and allcaps versions of all the identifiers in your symbol table for proper error/warning reporting. And it remains in other languages mostly because of cargo-cult language design. (That's the way it is in C, so it must be good, right?)

    The trouble with this post is I can't tell whether the guy is serious, in which case it's hilarious, or whether he's trying to make a joke, in which case it's not.

    I'm absolutely serious, TYVM. Case sensitivity is a huge mess that allows for all sorts of ugly abuses. Whenever I see someone writing something in C like "HWND hwnd;" I wanna throttle them. With the exception of a few proper nouns that are also normal concepts, a word means the same thing no matter how we capitalize it, so why shouldn't an identifier written as a word?

    Go on buddy, take a chance.....

    visit 'Pen Island' www.penisland.com

    How much does a blue pen cost? Waht about a red one?

    While for words case may not be overly sensitive in language, something like variables that (admittedly by convention) can be many words run together can be very sensitive!!

  • Gatesy (unregistered) in reply to ctw
    ctw:
    wtf:
    Mason Wheeler:

    Case sensitivity was allowed on C, like so many of its other misfeatures, simply because it's easier to implement...

    The trouble with this post is I can't tell whether the guy is serious, in which case it's hilarious, or whether he's trying to make a joke, in which case it's not.

    No, this is true. C is really easy to write a (non-optimizing) compiler for. This was, back in the day, considered a major feature of C, and according to some people is the reason for C's runaway success: http://www.jwz.org/doc/worse-is-better.html

    1. I wonder what OS he uses
    2. As a (predominently UNIOX-based) C-Programmer, I couldn't help replace C for VB and UNIX for window - WOW same principal - dumb down the masses
    <Digression> On a side note, there are (potentially) fewer than 50% of computers below the median (and on the balance of probability {read: my opinion}, the ones below will be closer the median than those above).

    Consider: 1,3,3,3,3,3,3,3,3,5 Median = 3 Mean = 3 Number of elements below median = 1 Number of elements above median element =1 50% # of elements = 5 (Number of elements)/2 > number of elements below median.

    </Digression>
  • FuBar (unregistered) in reply to Voo
    Voo:
    In german for example the uppercase for ß is SS, so SS should be equivalent to ss as well as ß. Considering that unicode contains lots of languages, who all have their little quirks I'm pretty sure the whole undertaking will get quite fun to implement and confuse absolutely everyone.
    Fun to implement, yes. Confuse everyone, i.e. programmers, no. If it is not true that toupper(ß) == toupper(ss) == toupper(SS) then your toupper() is broken. You just need to toupper() everything prior to doing a string compare.
  • MOASUT (unregistered) in reply to Rick
    Rick:
    Somewhat off topic trivia question...

    The traditional Unix file systems allow 254 of the 256 ASCII values to be used as characters in a file name. Name the other two.

    Carriage Return Line Feed

  • MOASUT (unregistered) in reply to Earp
    Earp:
    This would never have happened in VB...

    Are VB fans pedantic about calling it VB or is vb (Vb, vB etc) ok (or is that OK) too....?

    Hmmm, but case isn't important.....

  • (cs) in reply to gri
    gri:
    Paul:
    I use a language which doesn't mind about cases, and an IDE that will normalise the case to the version used in the declaration.

    TRWTF is languages that think i and I are different variables

    I = me i = loop counter

    Two very different variables in my book....

    Anyone who uses either of those for a variable name needs to be shot.

  • (cs) in reply to Ralph
    Ralph:
    EvanED:
    If people hadn't made the stupid decision back in the 60s to have a case-sensitive file system in the first place, there wouldn't have been a separate Makefile and MAKEFILE in the first place. ;-)
    But they did. So now, when you change things, you break stuff.
    Who "changed" things? I suppose that project could be SO old that there weren't case-insensitive file systems in wide use at the time, but considering that they have been in wide use in some systems for about three decades, it's a bit misleading to say that they "changed."
    * A search engine is going to think example.com/Index.asp is a different page from example.com/index.asp (and INDEX.asp and so on...) cluttering up search results.
    • Your browser is also going to think they are different, so things like the highlighted underline that shows whether you've visited this page before or not will be wrong.

    • Caching proxy servers retain multiple copies of the same thing in cache, consuming resources and reducing performance.

    • Same for your browser's cache.

    Fair enough on the first two; the cache thing was the only thing that occurred to me.

    * I saw a CIO of a large organization fired because the auditor found a significant increase in security vulnerabilities compared to the previous web scan. What if the "increase" was illusory, because the same URLs were counted multiple ways? Clever way to get your CIO fired, I suppose...
    What if it was? Then it would be really easy to show why the increase was illusory.
    Those are just the first few examples I can think of. But you arrogantly assumed there weren't any, because you weren't aware of any.
    Where did I assume there weren't any? OK, I was being a bit challenging, but it was in large part an actual question.
    And your assumption that it could all be handled at the server end means you don't have the necessary clue to be working web development.
    And your statement that it couldn't means you don't have the necessary clue to be working in development in general.

    Here, I'll show you how the web server could provide enough emulation of a case-sensitive file system to make it indistinguishable from the outside:

    handle_request(url) {
      requested_file = url_to_local_filename(url);
      canonical_name = get_canonical_case(requested_file);
      if (requested_file != canonical_name) {
        return_error_404();
      }
      else {
        return_file(requested_file);
      }
    }

    The 'canonical_case' function is pretty realistic; basically all case-insensitive file systems in current use are case-preserving and store the capitalization that the user originally gave a file.

    If you'd like, I'm pretty sure I could write you one for Windows.

    Not saying it's the most elegant solution, but it would work.

    Joops:
    Should compilers also try to find spelling errors in keywords and variables?
    Actually I've thought for a while that it'd be an interesting idea to see an interactive compiler: one that, if it encounters an error, makes a guess as to what you meant and asks you. Think of what happens if you run a/ispell on a file, except that it does it during compilation for errors.

    IDEs have some of this, but I don't think I've one that gives you suggestions in the same way that, say, word processors do. (I believe Eclipse underlines spelling errors for you even in identifiers, which is pretty awesome.)

    (Of course, I'm in no way saying that compilers should force you to use that mode.)

    Voo:
    Actually there's a wonderful technical reason why case insensitivity just won't work in lots of modern languages.

    Unicode. ... In german for example the uppercase for ß is SS, so SS should be equivalent to ss as well as ß. Considering that unicode contains lots of languages, who all have their little quirks I'm pretty sure the whole undertaking will get quite fun to implement and confuse absolutely everyone.

    IMO, that's only a good reason to avoid case-insensitivity, not a debate ending one. Unicode defines (slightly locale-dependent) case-folding operations, so there's not as much ambiguity as it might initially appear. The main problems are that it makes whether some code compiles or not locale-dependent and that if the locale doesn't match the programmer, he may be confused.

    Combined with the other reasons for case-sensitive names in programming languages, I think case-sensitivity is perfectly reasonable in that arena. However, I don't think the Unicode issues are enough to outweigh the arguments for my case-sensitive file system peeve.

    (And the examples get even more fun than what you say: is é made with U+00E9 ('latin small letter E with acute') the same as an é made with U+0301 ('combining acute accent') followed by U+0065 ('latin small letter E')?)

  • Your Name * (unregistered) in reply to Anonymous
    Anonymous:
    Personally I have no problem with case-sensitive variable names and I actually shudder a little imagining a language without them. The plain fact of the matter is that 'a' and 'A' are completely different characters as far as the computer is concerned - different char code, different character. Given this fact, it is obvious that uppercase and lowercase versions of the same word are different - they are not the same string, so why should the computer (or I) consider them to be the same? I'm happy with "what you see is what you get" - I don't want the compiler trying to be clever on my behalf by pretending that upper and lower cases are the same, because they patently aren't.

    Well, letters aren't really letters to a machine, they end up being compiled into binary. So perhaps we should just write in that? Oh wait, the code is meant for the programmer? Who'da thunk it?

    Programming languages are made to be clearly understood and a way for a human to communicate to a machine what it wants done. So, with the rare exception of "I helped my Uncle Jack off a horse" and "I helped my Uncle jack off a horse" capitalisation means very little to a human. Also, to counter it with the clarity argument, "Talk" "talk" "TALK" "TaLk" TAlk" "taLK" while looking stupid, all mean the same thing to a human.

  • (cs) in reply to wtf
    wtf:
    One-off ints are i, j, k, by convention. If they're persistent, they get descriptive names.

    By convention? Ohhh so you are writing in FORTRAN.

  • (cs) in reply to Ralph
    Ralph:
    * A search engine is going to think example.com/Index.asp is a different page from example.com/index.asp (and INDEX.asp and so on...) cluttering up search results.
    • Your browser is also going to think they are different, so things like the highlighted underline that shows whether you've visited this page before or not will be wrong.

    • Caching proxy servers retain multiple copies of the same thing in cache, consuming resources and reducing performance.

    • Same for your browser's cache.

    • I saw a CIO of a large organization fired because the auditor found a significant increase in security vulnerabilities compared to the previous web scan. What if the "increase" was illusory, because the same URLs were counted multiple ways? Clever way to get your CIO fired, I suppose...

    Yes, clients can (and some do, each their own unique way) check the content to see if the two URLs are really the same. But dynamic URLs change from one load to the next, causing a lot of extra work and incorrect decisions because some lazy programmer can't remember when to use upper vs. lower case.

    Those are just the first few examples I can think of. But you arrogantly assumed there weren't any, because you weren't aware of any.

    So regarding "IIS not burning in flames", your inability to recognize a fire doesn't mean you're safe to sleep in a burning house.

    And your assumption that it could all be handled at the server end means you don't have the necessary clue to be working web development.

    Ahh yes, because obviously in a URL there is only one way to specify the character "i" So it is impossible to have two different URLs that reference the same file even for case sensitive OSs

  • Ouch! (unregistered) in reply to Your Name *
    Your Name *:
    Anonymous:
    Personally I have no problem with case-sensitive variable names and I actually shudder a little imagining a language without them. The plain fact of the matter is that 'a' and 'A' are completely different characters as far as the computer is concerned - different char code, different character. Given this fact, it is obvious that uppercase and lowercase versions of the same word are different - they are not the same string, so why should the computer (or I) consider them to be the same? I'm happy with "what you see is what you get" - I don't want the compiler trying to be clever on my behalf by pretending that upper and lower cases are the same, because they patently aren't.

    Well, letters aren't really letters to a machine, they end up being compiled into binary. So perhaps we should just write in that? Oh wait, the code is meant for the programmer? Who'da thunk it?

    Programming languages are made to be clearly understood and a way for a human to communicate to a machine what it wants done. So, with the rare exception of "I helped my Uncle Jack off a horse" and "I helped my Uncle jack off a horse" capitalisation means very little to a human. Also, to counter it with the clarity argument, "Talk" "talk" "TALK" "TaLk" TAlk" "taLK" while looking stupid, all mean the same thing to a human.

    Depends on where you come from, I suppose. First, capitalisation has meaning in some natural languages. More importantly, with a mathematical background the idea that capitalisation shouldn't matter in formal languages seems bizarre. It's a centuries-old convention that X and x, F and f refer to different entities. Often capitalisation is used to indicate the domain an entity belongs to (x is a set, X a class; X is a set, x a point). If you've grown up with these conventions, case-sensitivity is so natural to you that the idea of case-insensitive programming languages seems fundamentally wrong.

    If you've been brought up on the idea that programming languages should resemble natural language (one of the worst ideas in programming ever, IMO), I guess case-insensitivity makes more sense.

  • RandomUser423702 (unregistered) in reply to MOASUT
    MOASUT:
    Earp:
    This would never have happened in VB...
    Are VB fans pedantic about calling it VB or is vb (Vb, vB etc) ok (or is that OK) too....?

    Hmmm, but case isn't important.....

    VB may be case-insensitive, but it is also (by convention) case-preserving. (I pity those insane enough to not only be writing VB, but doing it outside the IDE.) So, since it was declared as VB, VB it shall remain.

  • (cs) in reply to EvanED
    EvanED:
    Ralph:
    EvanED:
    If people hadn't made the stupid decision back in the 60s to have a case-sensitive file system in the first place, there wouldn't have been a separate Makefile and MAKEFILE in the first place. ;-)
    But they did. So now, when you change things, you break stuff.
    Who "changed" things? I suppose that project could be SO old that there weren't case-insensitive file systems in wide use at the time, but considering that they have been in wide use in some systems for about three decades, it's a bit misleading to say that they "changed."
    And just to be more clear, I went through the Wikipedia table of file systems looking at case-insensitive systems. According to it, RS-11 had a case insensitive file-system in 1970, and then CP/M came along just a couple years later. There were a number of others in the 70's as well. In fact, at least with a quick skim over the pages, these case-insensitive file systems may predate the earliest case-sensitive file system that actually appears in that list. (There's some ambiguity over whether the UFS1 that appears in that table is the file system from the original Unix implementations. Even if it does formally appear in the list, it's still of the same era as RT-11.)

    So it's not like MS came along and decided to "change" things after Unix was well-established or anything like that.

    Addendum (2010-11-03 20:01):

    Ouch!:
    Depends on where you come from, I suppose. First, capitalisation has meaning in some natural languages. More importantly, with a mathematical background the idea that capitalisation shouldn't matter in formal languages seems bizarre. It's a centuries-old convention that X and x, F and f refer to different entities. Often capitalisation is used to indicate the domain an entity belongs to (x is a set, X a class; X is a set, x a point). If you've grown up with these conventions, case-sensitivity is so natural to you that the idea of case-insensitive programming languages seems fundamentally wrong.

    If you've been brought up on the idea that programming languages should resemble natural language (one of the worst ideas in programming ever, IMO), I guess case-insensitivity makes more sense.

    Well, of course, we programmers actually tend to spell out our variable names fortunately, instead of using single-character glyphs for everything. One reason that "X is a set, x a point" is so prevalent in mathematics is because they resist notions like saying "p \in points" or stuff like that.

    If you open your world to multi-character identifiers, that both increases the number of available identifiers and makes it possible to show relations between them with more than just "this is lowercase and this is capital."

    Finally, I think the example you choose is actually particularly bad, because there are plenty of situations (many people's handwriting) where the 'x/X' distinction can actually be very difficult to make out and you have to guess by context. Of course, that doesn't really apply in the world of computer text, but I do find it a little amusing.

  • RandomUser423702 (unregistered) in reply to Voo
    Voo:
    Actually there's a wonderful technical reason why case insensitivity just won't work in lots of modern languages.

    Unicode.

    Well that and the fact that there are valid programs out there that'd break, but back to the more interesting part. As soon as you allow unicode for variable characters (well I could live without it, so that would be an alternative) the conversion between lowercase and uppercase isn't unique any longer. In german for example the uppercase for ß is SS, so SS should be equivalent to ss as well as ß. Considering that unicode contains lots of languages, who all have their little quirks I'm pretty sure the whole undertaking will get quite fun to implement and confuse absolutely everyone.

    VB.NET's "solution":
    Visual Basic Language Specification:
    2.2 Identifiers

    An identifier is a name. Visual Basic .NET identifiers conform to the Unicode Standard Annex 15 with one exception: identifiers may begin with an underscore (connector) character. If an identifier begins with an underscore, it must contain at least one other valid identifier character to disambiguate it from a line continuation.

    ...

    Identifiers are case insensitive, so two identifiers are considered to be the same identifier if they differ only in case. Note The Unicode Standard one-to-one case mappings are used when comparing identifiers, and any locale-specific case mappings are ignored.

  • Jimbo (unregistered) in reply to EvanED
    EvanED:
    Joops:
    Should compilers also try to find spelling errors in keywords and variables?
    Actually I've thought for a while that it'd be an interesting idea to see an interactive compiler: one that, if it encounters an error, makes a guess as to what you meant and asks you. Think of what happens if you run a/ispell on a file, except that it does it during compilation for errors.

    IDEs have some of this, but I don't think I've one that gives you suggestions in the same way that, say, word processors do. (I believe Eclipse underlines spelling errors for you even in identifiers, which is pretty awesome.)

    (Of course, I'm in no way saying that compilers should force you to use that mode.)

    A) I'm not sure you appreciate how complicated error handling in the compiler already is without spell-check type functionality (although allowing code to be corrected as the compiler encounters it does sound nice, sometimes the point where the problem is identified is well after where the problem occured - what if you mis-spelt the declaration?) B) Many IDE's highlight variables they don't know (and this is a good thing), but it doesn't (to me anyways) suggest case insensitivity is a good thing....

    I'm quite happy for a compiler to assume that the person using it has some idea of what they are doing. Time and time again we seem to find issues when people try to cater for stupid users. The solution is educating users, not dumbing down applications - and I think the same applies here.

    We see spectacular examples of how inefficient auto-generated code appears to be (because we work off simplified rules to do sometimes quite complex tasks), andf I would suggest that trying to guess what programmer's meant would be somewhat more complex again.

    Already, given the articles (and, dare I say, comments) we see here programmers are lazy and lacking in knowledge. Trying to simplify the the task is the wrong approach - Educating the Programmer is the right approach.

    Or we could just use robots to write our programs...you choose!

  • Jimbo (unregistered) in reply to Your Name *
    Your Name *:
    Anonymous:
    Personally I have no problem with case-sensitive variable names and I actually shudder a little imagining a language without them. The plain fact of the matter is that 'a' and 'A' are completely different characters as far as the computer is concerned - different char code, different character. Given this fact, it is obvious that uppercase and lowercase versions of the same word are different - they are not the same string, so why should the computer (or I) consider them to be the same? I'm happy with "what you see is what you get" - I don't want the compiler trying to be clever on my behalf by pretending that upper and lower cases are the same, because they patently aren't.

    Well, letters aren't really letters to a machine, they end up being compiled into binary. So perhaps we should just write in that? Oh wait, the code is meant for the programmer? Who'da thunk it?

    Programming languages are made to be clearly understood and a way for a human to communicate to a machine what it wants done. So, with the rare exception of "I helped my Uncle Jack off a horse" and "I helped my Uncle jack off a horse" capitalisation means very little to a human. Also, to counter it with the clarity argument, "Talk" "talk" "TALK" "TaLk" TAlk" "taLK" while looking stupid, all mean the same thing to a human.

    I woudl say Programming languages are made to find a blance between clear comprehensin by programmer's, and minimised risk of compiler's getting it wrong.

    Perhaps we should ban capital letters in programs?

  • MOASUT (unregistered) in reply to RandomUser423702
    RandomUser423702:
    MOASUT:
    Earp:
    This would never have happened in VB...
    Are VB fans pedantic about calling it VB or is vb (Vb, vB etc) ok (or is that OK) too....?

    Hmmm, but case isn't important.....

    VB may be case-insensitive, but it is also (by convention) case-preserving. (I pity those insane enough to not only be writing VB, but doing it outside the IDE.) So, since it was declared as VB, VB it shall remain.

    But if I call it vB they should still understand, right? Because how it was declared is not important...

  • RandomUser423702 (unregistered)

    Speaking of Unicode: any thoughts on whether

    redWagon

    and

    redWagon

    should be considered the same identifier?

  • hqppy (unregistered) in reply to EvanED
    EvanED:

    Addendum (2010-11-03 20:01):

    Ouch!:
    Depends on where you come from, I suppose. First, capitalisation has meaning in some natural languages. More importantly, with a mathematical background the idea that capitalisation shouldn't matter in formal languages seems bizarre. It's a centuries-old convention that X and x, F and f refer to different entities. Often capitalisation is used to indicate the domain an entity belongs to (x is a set, X a class; X is a set, x a point). If you've grown up with these conventions, case-sensitivity is so natural to you that the idea of case-insensitive programming languages seems fundamentally wrong.

    If you've been brought up on the idea that programming languages should resemble natural language (one of the worst ideas in programming ever, IMO), I guess case-insensitivity makes more sense.

    Well, of course, we programmers actually tend to spell out our variable names fortunately, instead of using single-character glyphs for everything. One reason that "X is a set, x a point" is so prevalent in mathematics is because they resist notions like saying "p \in points" or stuff like that.

    If you open your world to multi-character identifiers, that both increases the number of available identifiers and makes it possible to show relations between them with more than just "this is lowercase and this is capital."

    Finally, I think the example you choose is actually particularly bad, because there are plenty of situations (many people's handwriting) where the 'x/X' distinction can actually be very difficult to make out and you have to guess by context. Of course, that doesn't really apply in the world of computer text, but I do find it a little amusing.

    Let me get this straight, so we increase the number of available identifiers by increasing the allowed length while decreasing the number available by insisting that case is irrelevant?

    Programming is a science (branching from Math, I guess). As such consistency and precision (though not necessarily accuracy) is important. Scientists don't write "Thingammybob was red" and later "Thingummyjig didn't...." - and neither should programmers.
    A previous poster alludes to the fact that Programming Languages developed in an attempt at readability. This may well be true, however to reduce the possibility of unexpected behaviour, a certain rigidness must be maintained. Thus, programming languages should sufficiently reduce machine code into something understandable by humans, while minimising any adverse affect (which is inherent once you start to guess at what the programmer meant - which is essentially what ignoring case is). Once you accept that 'red' and 'Red' are the same thing, do we then try phonetics as well? Does 'Read' fit in here? Should l33tspeak be translated too (those who argue the mind can work case out - the mind (for most people) can work out l33tspeak too).

    Before reading this debate, I thought 'case sensitive is right, but if people want to do it differently who cares', but I've actually been convinced that people who advocate case insensitivity are, on the whole, nut-jobs!!

    I like that my compiler trusts me! I like that it doesn't want to assume. I like that when it's unsure, it would rather fail so that I give it clear instructions.

    People here often say that VB breeds bad programmers, I'm really starting to wonder whether bad programmers bred VB...

  • RandomUser423702 (unregistered) in reply to MOASUT
    MOASUT:
    RandomUser423702:
    MOASUT:
    Earp:
    This would never have happened in VB...
    Are VB fans pedantic about calling it VB or is vb (Vb, vB etc) ok (or is that OK) too....?

    Hmmm, but case isn't important.....

    VB may be case-insensitive, but it is also (by convention) case-preserving. (I pity those insane enough to not only be writing VB, but doing it outside the IDE.) So, since it was declared as VB, VB it shall remain.

    But if I call it vB they should still understand, right? Because how it was declared is not important...

    Under your (apparent) premise that your discussion of VB should conform to the behavior of VB, your statement is flawed. The capitalization is forced to match that used in the declaration. That you even emitted the identifier "VB" without all caps would indicate that you are in the middle of composing your statement (please finish what you start) or not using the IDE (you would have my pity, as previously stated).

    Regardless, the only real-life circumstances I can imagine where they would not understand you if you used mixed-case are situations so lacking in context that using the correct casing would produce similar results. Whether they may think you are lazy, an idiot, or a moron is a different question that I cannot answer.

  • aNoN (unregistered) in reply to Your Name *
    Your Name *:
    Programming languages are made to be clearly understood and a way for a human to communicate to a machine what it wants done. So, with the rare exception of "I helped my Uncle Jack off a horse" and "I helped my Uncle jack off a horse" capitalisation means very little to a human. Also, to counter it with the clarity argument, "Talk" "talk" "TALK" "TaLk" TAlk" "taLK" while looking stupid, all mean the same thing to a human.

    sO YoU thINk hUManS haVE NO pRObLEm rEAding RanD0m CASe?

    Would you want to read a long WTF if Alex wrote it using random casing like that? Doesn't it make it harder to read? Sure, you can read it...but it takes more effort, no?

    Code needs to be readable not only by the compiler, but also by humans. When you use a consistent naming and capitalization convention you increase the human readability factor of your code. Using the example posted above: HWND hwnd; Not only does context tell you that HWND and hwnd are different, but Microsoft is fairly good at using consistent naming conventions, so once you get the feel for them, they become part of your reading skills.

    If I saw some MFC code like this: PostMessage(hwnd,...) I know exactly what hwnd had better be. It's a variable of type HWND. I don't need to go look at the definition. But if I see this: PostMessage(HWND,..) By brain says WTF? Now I have to go look at the definition of HWND And if I see this: PostMessage(HwNd,...) I would run away, very, Very, VeRy, VERY fast.

  • (cs) in reply to Jimbo

    And to reiterate, I'm not really advocating that programming languages should be case-insensitive. I'm just advocating that it's not at all unreasonable, as a language designer, to make that decision. One of my top couple favorite languages, Lisp, is more-or-less case-insensitive in almost all its dialects.

    Jimbo:
    A) I'm not sure you appreciate how complicated error handling in the compiler already is without spell-check type functionality (although allowing code to be corrected as the compiler encounters it does sound nice, sometimes the point where the problem is identified is well after where the problem occured - what if you mis-spelt the declaration?)
    I do realize that making compilers produce readable error messages is very difficult; I have from time to time compiled a program with a different compiler to see if it produced a more helpful diagnostic. (I've also taught a compiler class, though admittedly I don't really know much about that particular aspect of it.) A general "did you mean this?" suggestion mechanism would probably be extraordinarily difficult. (Though Eclipse does suggest some things for some kinds of errors/warnings.)

    That said, I'm struggling to see how spell-checking would add much complexity to a compiler. There's probably limited places where the complier can emit a "I haven't seen this identifier before" error, and you'd just have to patch into each of them a mechanism to traverse the current symbol table and look for things that are close. Then just replace the current value with what the user said.

    B) Many IDE's highlight variables they don't know (and this is a good thing), but it doesn't (to me anyways) suggest case insensitivity is a good thing....

    Oh, sure, I'll agree there. I just don't think that "the complier shouldn't look for spelling errors" isn't a very good argument for case-sensitivity.

    Jimbo:
    Perhaps we should ban capital letters in programs?

    I'm not a fan of this suggestion, but it is a little related to what Haskell does. You know all those coding standards like "variables start with a lowercase letter, types start with an uppercase letter", etc.? Haskell enforces some of them. An identifier starting with a lowercase letter is a function, variable, etc., and lexically speaking, cannot be a type.

    Another potential compromise is this: the language is case-insensitive in the sense that you can't have a variable called "foo" and another called "Foo", but case-sensitive in the sense that you must use the same capitalization that you used in the declaration.

    Again, I'm not particularly advocating any of these (though I do like a combination of those), just tossing ideas out there.

    hqppy:
    Let me get this straight, so we increase the number of available identifiers by increasing the allowed length while decreasing the number available by insisting that case is irrelevant?

    To some extent yes; I would argue that's exactly what is happening in languages that decide to go the case-insensitive route. Though I do think that the "there are other ways of indicating relations between objects" is more important than just the number of available identifiers.

    Programming is a science (branching from Math, I guess). As such consistency and precision (though not necessarily accuracy) is important. Scientists don't write "Thingammybob was red" and later "Thingummyjig didn't...." - and neither should programmers.

    No, of course they shouldn't. But that's rather a strawman, don't you think? Physicists don't exactly go around saying that the sentences "there are several types of quarks" and "there are several types of Quarks" mean entirely different things.

    Before reading this debate, I thought 'case sensitive is right, but if people want to do it differently who cares', but I've actually been convinced that people who advocate case insensitivity are, on the whole, nut-jobs!!

    Does that include John McCarthy? Or is he an exception to your "on the whole"?

    (Okay, that may not be quite fair... I can't say for sure that the original LISP was case-insensitive. In fact, I can't say for sure that it was even written on a machine that could produce lowercase letters. :-) But still, basically every Lisp dialect out there I know of except for one is mostly case-insensitive; are all those people nut-jobs?)

  • Coder (unregistered) in reply to Zylon
    Zylon:
    What IS the argument for case-sensitive names, anyway?

    Early computers didn't do typesetting. This was primarily a limitation of the IO systems: for example, standard programming cards and teletypes did not have uppercase/lower case representations.

    When computer systems (in particular, IO systems) did come out that could do upper case/lower case, their programmmers were so impressed with the damm cleverness of it all, they uSed UPPER case and lower CASE everywhere.

    The character representation was designed so that a simple bit mask could make everything case-insensitive, but where's the fun in that?

    TO BE FAIR, EVERYONE WAS SICK OF CASELESS PROGRAMMING, SO IT REALLY DID LOOK CLEVER AT FIRST.

  • (cs) in reply to K
    K:
    Phlip:
    I was about to post a comment about how PHP is case-insensitive anyway, but having tried it, it seems that variable names in PHP are case-sensitive. Functions in PHP are case-insensitive; hell, even keywords like "if" are case-insensitive. But variables are case-sensitive.

    What the hell, PHP?

    If that statement is true, then it deserves to by highlighted.
    It's true, try it:

    phlip@boris:~$ php -r '$a = "Hello"; print "$a\n";' # running PHP from command line
    Hello
    phlip@boris:~$ php -r '$a = "Hello"; PRINT "$a\n";' # case-insensitive keywords
    Hello
    phlip@boris:~$ php -r '$a = "Hello"; IF(strlen($a) < 10) Print "Yes\n";' # more case-insensitive keywords
    Yes
    phlip@boris:~$ php -r '$a = "Hello"; IF(STRlen($a) < 10) Print "Yes\n";' # case-insensitive functions
    Yes
    phlip@boris:~$ php -r '$a = "Hello"; print $A;' # case-insensitive variables?
    PHP Notice:  Undefined variable: A in Command line code on line 1
  • Coder (unregistered) in reply to Voo
    Voo:
    Actually there's a wonderful technical reason why case insensitivity just won't work in lots of modern languages. Unicode. ...I'm pretty sure the whole undertaking will get quite fun to implement and confuse absolutely everyone.

    Fourtunately, the Unicode people have already done it for you. Case mappings are provided in the Unicode database, at unicode.org

  • noland (unregistered) in reply to Bob

    As we have seen some solutions for Perl, here's how to do in PHP:

    // returns the value for the first matching global variable name
    function getValueForVarNamePattern($pattern) {
        $matches = array_values( preg_grep( $pattern, array_keys($GLOBALS) ) );
        return (empty($matches))? '' : $GLOBALS[$matches[0]];
    }
    
    $bar='foobar';
    $foo = getValueForVarNamePattern('/^BAR$/i');
    // $foo == 'foobar'
    
  • noland (unregistered) in reply to noland
    noland:
    As we have seen some solutions for Perl, here's how to do in PHP:
    // returns the value for the first matching global variable name
    function getValueForVarNamePattern($pattern) {
        $matches = array_values( preg_grep( $pattern, array_keys($GLOBALS) ) );
        return (empty($matches))? '' : $GLOBALS[$matches[0]];
    }
    

    $bar='foobar'; $foo = getValueForVarNamePattern('/^BAR$/i'); // $foo == 'foobar'

    Obviously it should be:

        return (empty($matches))? null : $GLOBALS[$matches[0]];
    

    but for the purpose of this site it's rather:

        return (empty($matches))?
            'FILE NOT FOUND (This is an embedded system!)' 
            : $GLOBALS[$matches[0]];
    
  • (cs) in reply to noland
    noland:
    noland:
    As we have seen some solutions for Perl, here's how to do in PHP:
    // returns the value for the first matching global variable name
    function getValueForVarNamePattern($pattern) {
        $matches = array_values( preg_grep( $pattern, array_keys($GLOBALS) ) );
        return (empty($matches))? '' : $GLOBALS[$matches[0]];
    }
    

    $bar='foobar'; $foo = getValueForVarNamePattern('/^BAR$/i'); // $foo == 'foobar'

    Obviously it should be:

        return (empty($matches))? null : $GLOBALS[$matches[0]];
    

    but for the purpose of this site it's rather:

        return (empty($matches))?
            'FILE NOT FOUND (This is an embedded system!)' 
            : $GLOBALS[$matches[0]];
    

    Nice! That's an ingenious combination of memes.

  • leGrande (unregistered) in reply to EvanED
    EvanED:
    Before reading this debate, I thought 'case sensitive is right, but if people want to do it differently who cares', but I've actually been convinced that people who advocate case insensitivity are, on the whole, nut-jobs!!

    Does that include John McCarthy? Or is he an exception to your "on the whole"?

    (Okay, that may not be quite fair... I can't say for sure that the original LISP was case-insensitive. In fact, I can't say for sure that it was even written on a machine that could produce lowercase letters. :-) But still, basically every Lisp dialect out there I know of except for one is mostly case-insensitive; are all those people nut-jobs?)

    I read the OP to be saying that people who promote the idea (of case insensitivity) as a good one are largely mad, rather than people who happen to use a language that is case insensitive are mad...({as you point out} there is little to suggest that LISP was ever meant to be case insensitive - or that the creator intended it that way - and frankly if he did so believing it was a good thing, then yes, he either didn't think it through or was mad {which most of us {?} mathematical types could be accused of being)

    could be worng, but that's what it sounded like to me....

  • (cs) in reply to leGrande
    leGrande:
    I read the OP to be saying that people who promote the idea (of case insensitivity) as a good one are largely mad, rather than people who happen to use a language that is case insensitive are mad...({as you point out} there is little to suggest that LISP was ever meant to be case insensitive - or that the creator intended it that way - and frankly if he did so believing it was a good thing, then yes, he either didn't think it through or was mad {which most of us {?} mathematical types could be accused of being)

    could be worng, but that's what it sounded like to me....

    But there have been many dialects of Lisp created since then, and basically all are case-insensitive. That just means that there are even more people who have acted as language designers on the different dialects: are all of them mad? E.g. Guy Steele and Gary Sussman? (Actually, it's funny... I just remembered when I was writing this up that R6RS was changed to a case-sensitive reader.)

  • Holo (unregistered) in reply to Ouch!

    Dork man

  • tovarich (unregistered) in reply to Sutherlands
    Sutherlands:
    gri:
    Paul:
    I use a language which doesn't mind about cases, and an IDE that will normalise the case to the version used in the declaration.

    TRWTF is languages that think i and I are different variables

    I = me i = loop counter

    Two very different variables in my book....

    Anyone who uses either of those for a variable name needs to be shot.
    So, we'll have to put every author of every for-loop example ever written against the wall then?

  • Ben (unregistered) in reply to Voo
    Voo:
    Actually there's a wonderful technical reason why case insensitivity just won't work in lots of modern languages.

    Unicode.

    Well that and the fact that there are valid programs out there that'd break, but back to the more interesting part. As soon as you allow unicode for variable characters (well I could live without it, so that would be an alternative) the conversion between lowercase and uppercase isn't unique any longer. In german for example the uppercase for ß is SS, so SS should be equivalent to ss as well as ß. Considering that unicode contains lots of languages, who all have their little quirks I'm pretty sure the whole undertaking will get quite fun to implement and confuse absolutely everyone.

    And that's precisely why the unicode consortium developed normal forms: http://unicode.org/reports/tr15/

  • Rhialto (unregistered) in reply to Philipp

    TRWTF is... how everybody confuses the email with the email address...

  • TRWTF (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    wtf:
    Mason Wheeler:

    Case sensitivity was allowed on C, like so many of its other misfeatures, simply because it's easier to implement. Case sensitivity makes for simpler string comparisons and you don't have to store both original and allcaps versions of all the identifiers in your symbol table for proper error/warning reporting. And it remains in other languages mostly because of cargo-cult language design. (That's the way it is in C, so it must be good, right?)

    The trouble with this post is I can't tell whether the guy is serious, in which case it's hilarious, or whether he's trying to make a joke, in which case it's not.

    I'm absolutely serious, TYVM. Case sensitivity is a huge mess that allows for all sorts of ugly abuses. Whenever I see someone writing something in C like "HWND hwnd;" I wanna throttle them. With the exception of a few proper nouns that are also normal concepts, a word means the same thing no matter how we capitalize it, so why shouldn't an identifier written as a word?

    An identifier, by its very nature, must uniquely identify something. "MYID" and "myid" are two completely different words composed of completely different char codes, yet you want these completely different identifiers to resolves to the SAME variable?

    That, my friends, is TRWTF. You seem to understand the fact that a variable name is a unique identifier yet you don't seem to think it has to be unique. I fail to comprehend how any intelligent person could come to this conclusion.

  • Me, Myself and i (unregistered) in reply to Sutherlands
    Sutherlands:
    gri:
    Paul:
    I use a language which doesn't mind about cases, and an IDE that will normalise the case to the version used in the declaration.

    TRWTF is languages that think i and I are different variables

    I = me i = loop counter

    Two very different variables in my book....

    Anyone who uses either of those for a variable name needs to be shot.
    Using i for a loop index is one of the oldest programming conventions I know. I've seen this in code written in the 70s and I've seen this in code written yesterday. I really don't see the problem, especially if you are constructing a for clause (one line) and you want to be able to actually read the clause without it spilling off the page due to an indexer variable with an unnecessarily long name. I would argue that anything longer that 1 char for a loop indexer is just a waste of line length and a detriment to readability - of course, this is a general rule and there will always be exceptions on a case by case basis.

    Conclusion: if you can't get used to i as an indexer variable I don't see you'll ever get used to software development as a profession.

  • Anonymous (unregistered) in reply to Your Name *
    Your Name *:
    Anonymous:
    Personally I have no problem with case-sensitive variable names and I actually shudder a little imagining a language without them. The plain fact of the matter is that 'a' and 'A' are completely different characters as far as the computer is concerned - different char code, different character. Given this fact, it is obvious that uppercase and lowercase versions of the same word are different - they are not the same string, so why should the computer (or I) consider them to be the same? I'm happy with "what you see is what you get" - I don't want the compiler trying to be clever on my behalf by pretending that upper and lower cases are the same, because they patently aren't.
    "I helped my Uncle Jack off a horse"

    "I helped my Uncle jack off a horse"

    "Capitalisation means very little to a human."

    Great job on proving my point and thoroughly contradicting yourself in the process. Captialisation is fully understood by all humans, we understand it and we care about it and it is relevant to the words we read and write. I think computers and especially compilers should honour this fact, unless you really want to help your uncle pleasure that stud of his.
  • Indigo (unregistered) in reply to Anonymous
    Great job on proving my point and thoroughly contradicting yourself in the process.
    Whoa, great job of completely misquoting someone!

    The poster was entirely aware of the contradiction you stated - the poster themself stated it very clearly: "with the rare exception of" You yourself never addressed this crucial argument of theirs (rarity), but just merrily moved on to argue the exact same point they already presented an argument against. Fail.

    we understand [capitalization] and we care about it and it is relevant to the words we read and write.
    Of course we understand it. but no, iT reaLLy ISn't very relEVaNT in mOST caSes. In basic use, it's role is to provide visual structure to text (whether it does as good job at that is an entirely different issue - at least lojbanists would argue against). In some cases it's used as a simple way to provide EMPHASIS, and in some cases it's used to highLITE specific parts of words - which is in fact pretty similar use to general emphasis. Only in very rare cases, such as the one stated, does it actually affect the semantics - the meaning.

    The most common of these rare cases is capitalization as indication of a name ("I'm going to the Hills" vs. "I'm going to the hills"), another one would be "elevation" of an instance to more importance or higher stature - which is again sort of similar to emphasis but this time it's more of a semantic emphasis ("That's not just a dog, that, my friend, is a Dog!") The thing is, these are very rare cases, and I can't think of a single example where such as case would be at all relevant in a programming context.

    However, I actually sort-of agree with the case-sensitive side of this argument (although I'd like the sort of case-sensitivity that still throws an error from trying to have any case-insensitively conflicting cases at the same time).

    But please never do such an ugly, ugly misquotation of someone ever again. Geez.

  • Guran (unregistered) in reply to Zylon
    Zylon:
    What IS the argument for case-sensitive names, anyway?

    ...and the number one argument for case-sensitive names is (drum roll) VB uses case-insensitive names.

  • frits (unregistered) in reply to PinkyAndTheBrainFan187
    PinkyAndTheBrainFan187:
    frits:
    Me:
    frits:
    This is literally the lamest WTF that has ever been posted.

    Seriously, who hasn't had to do something like this?

    Me. I don't even understand what the coder is trying to do. Usually, the WTF has some kind of twisted logic, and I normally mentally translate unfamiliar code into one the coding languages I'm at least semi-familiar with, but this just doesn't make sense.

    So: global $EmailAddress (etc) produces a preassigned global variable? Which is then assigned to another global $email variable, which if false (or null?) results in another preassigned global variable, and so on? What's the point?

    If you can't figure this out, than your a moron. The email needs to get set from an ordered priority of places. The only thing is that they happen to be named similarly (except for case). Obviously, you could change the variable names elsewhere to this and it would be readible.

    if (!$email){
        global $primaryEmail; 
        $email=$primaryEmail; 
        if (!$email){ 
            global $secondaryEmail; 
            $email=$secondaryEmail;
            if (!$email){
                global $tertiaryEmail; 
                $email=$tertiaryEmail; 
                if (!$email){ 
                    global $email4; 
                    $email = $email4;
                    if (!$email){ 
                        global $email5; 
                        $email = $email5; 
                        if (!$email){ 
                            global $email6; 
                            $email = $email6; 
                        }
                    }
                }
            }
        }
    }
    

    Oh hi there frist! Err...yeah...TRWTF is calling someone a moron, pretending to be "smart" by using primary, secondary & tertiary as prefixes on your e-mail variables and then giving up and using numeral suffixes because you're too fucking stupid to know the words "quaternary", "quinary" and "senary".

    And all this in a comment on a WTF which boils down to stupidity and inconsistency in variable naming! Isn't it ironic? Don't ya think? You lovable little troll you! :x

    Captcha: ingenium (The irony of the troll was so ingenium I nearly plotzed).

    I think we both know who the troll is here. Most people don't known tertiary. Even fever know quaternary. I thought about stopping there, but I included it anyway. Irregardless, you can figure out what I intented.

  • lolguys (unregistered)

    Recent studies have shown that humans can understand written English without many of the letters. For instance.

    I wnt to te sprmket n stday nd bht a cbge.

    which is missing over a third of its letters.

    So by the logic that case sensitivity doesn't affect humans much, why not just abbreviate all variable names? I mean you can work it out from context can't you?

    Regardless of our ability to cope without capitalisation, we're used to it. Say you're scanning over a document for the word Saturday, you're mostly looking for word shape (that's how I do it anyway) rather than the letters, and you'll probably miss saturday on first reading. It makes it easier to read even if it's not essential for comprehension. It also allows things like HWND hwnd. Nowadays the abbreviation HWND is a bit rubbish, but if you're a Windows coder it makes perfect sense. hwnd is, and always will be, an HWND. If you don't understand why that's clear and obvious (especially if you're using lots of methods that Intellisense pops up the parameter HWND hwnd for) then you really shouldn't be coding.

  • Berry (unregistered) in reply to Rick
    Rick:
    Perl rather than PHP, but...
    $eMailAddress = '[email protected]';
    
    foreach my $key (keys %main::) {
        if($key =~ /emailaddress/i) {
            $email = $$key;
        }
    }
    

    print "$email\n";

    Although I'd try to avoid ever needing a piece of code that will loop through a bunch of variables to pick one of them, PHP can do the same as your perl script. Fun exercise though.

    <?php
    $EmailADDRESS = 'my-email-address';
    
    foreach( get_defined_vars( ) as $key => $value ) {
      if( 0 !== preg_match( '/email/i', $key ) ) {
        $email = $$key;
      }
    }
    
    print $email;
    ?>
    

    CAPTCHA: damnum

  • Anonymous (unregistered) in reply to Indigo
    Indigo:
    Great job of completely quoting someone!

    The poster already presented an argument against Fail.

    Please do such of someone again.

    Thanks for your support, I did rather assume that most intelligent folks would agree with me.

  • (cs) in reply to Ksevio
    Ksevio:
    One great thing about delphi is that names aren't case sensitive so you never run into problems like that. It actually saves a lot of time looking up variables in long functions/programs having to know what you're doing.
    FTFY. And then you have to write stuff like today's post, because you don't know what the bloody variable is called. Oh wait, are you assuming that you do know the name of every variable, just not the case? You're selectively amnesiac just for capitalisation?
    Ksevio:
    Also, what languages let you put a dash in a variable name?
    TCL, scheme, ruby... I expect there are more.
  • (cs) in reply to lolguys
    lolguys:
    Recent studies have shown that humans can understand written English without many of the letters. For instance.

    I wnt to te sprmket n stday nd bht a cbge.

    You went to the sperm-bucket and steadfastly anybody bullshitted a carpetbagger?
  • (cs)

    Fixed:

    global $Email, $Email_Address, $email_address, $EmailAddress, $emailaddress, $EMailAddress $email = $Email or $Email_Address or $email_address or $EmailAddress or $emailaddress or $EMailAddress

  • Joe (unregistered) in reply to no name

    Please make this a featured comment.

  • jl (unregistered) in reply to no name
    no name:
    Kempeth:
    Now if we could only specify the variable name in RegEx that would solve our problems...

    That would be an awesome language feature - just imagine the potential for abuse...

    FEATURED COMMENT!

Leave a comment on “The Email Tree”

Log In or post as a guest

Replying to comment #:

« Return to Article