Representative Line


  • Considered Harmful

    I'm doing maintenence on some old ASP.NET code I inherited from a coworker that has long since been let go for gross incompetence.  This snippet seemed a good representative line:

    <% IF ((Request.UserAgent.IndexOf("mac") >= 0 And Request.UserAgent.IndexOf("msie") >= 0) Or (Request.UserAgent.IndexOf("Mac") >= 0 And Request.UserAgent.IndexOf("Msie") >= 0 ) Or (Request.UserAgent.IndexOf("Mac") >= 0 And Request.UserAgent.IndexOf("MSIE") >= 0 ) Or (Request.UserAgent.IndexOf("MAC") >= 0 And Request.UserAgent.IndexOf("MSIE") >= 0 )) Then %>

    Yes, let's check each case permutation individually.  The markup inside the conditional block is even worse.  In fact, it's all terrible, but this snippet just happened to have a little humor in it (at least to me).  I can almost sense his frustration trying to get all the combinations to work properly.



  • Just once I want to see someone take this one step further into the realm of insanity:

    <% IF (Request.UserAgent.IndexOf("mac") >= 0 And Request.UserAgent.IndexOf("msie") >= 0) Then %>
    <a href="...">...
    <% ElseIf (Request.UserAgent.IndexOf("MAC") >= 0 And Request.UserAgent.IndexOf("MSIE") >= 0 ) Then %>
    <A href="...">...
    <% Else ((Request.UserAgent.IndexOf("Mac") >= 0 And Request.UserAgent.IndexOf("Msie") >= 0 ) Or (Request.UserAgent.IndexOf("Mac") >= 0 And Request.UserAgent.IndexOf("MSIE") >= 0 )) Then %>
    <A href="...">...



  • As someone who's never been exposed to ASP.NET (or any other kind of ASP, or .NET for that matter), may I assume that there is some ASP.NET equivalent to Java's: myString.equalsIgnoreCase("...") ?



  • @snoofle said:

    As someone who's never been exposed to ASP.NET (or any other kind of ASP, or .NET for that matter), may I assume that there is some ASP.NET equivalent to Java's: myString.equalsIgnoreCase("...") ?

    <FONT size=4>

    </FONT><FONT color=#0000ff size=4>bool</FONT><FONT size=4> equality = someString.Equals(otherString, </FONT><FONT color=#008080 size=4>StringComparison</FONT><FONT size=4>.InvariantCultureIgnoreCase);</FONT>

    <FONT size=2>The StringComparison enumeration has other five values you can pick, two of them also involve ignoring case.</FONT>



  • [quote user="Renan "C#" Sousa"]

    @snoofle said:

    As someone who's never been exposed to ASP.NET (or any other kind of ASP, or .NET for that matter), may I assume that there is some ASP.NET equivalent to Java's: myString.equalsIgnoreCase("...") ?

    <FONT size=4>

    </FONT><FONT color=#0000ff size=4>bool</FONT><FONT size=4> equality = someString.Equals(otherString, </FONT><FONT color=#008080 size=4>StringComparison</FONT><FONT size=4>.InvariantCultureIgnoreCase);</FONT>

    <FONT size=2>The StringComparison enumeration has other five values you can pick, two of them also involve ignoring case.</FONT>

    [/quote]

    As a minor nitpick of the OP being VB.NET/ASP.NET rather than C#/ASP.NET, that line would look more like:

    Dim equality As Boolean = someString.Equals(otherString, StringComparison.InvariantCultureIgnoreCase)

    You also have <font face="monospace">UCase</font> and <font face="monospace">LCase</font> (VB.NET-specific) as well as <font face="monospace">someString.ToUpperCase()</font> and <font face="monospace">someString.ToLowerCase()</font> (for all .NET languages), which can be useful if you need to do multiple case-mapped comparisons, as having already case-mapped the strings means the string compare need only be a straight byte comparison (and also saves you the work of case-mapping later if you need to store the result in something more permanent).



  • [quote user="Renan "C#" Sousa"]

    @snoofle said:

    As someone who's never been exposed to ASP.NET (or any other kind of ASP, or .NET for that matter), may I assume that there is some ASP.NET equivalent to Java's: myString.equalsIgnoreCase("...") ?

    <font size="4">
    </font>

    <font color="#0000ff" size="4">bool</font><font size="4"> equality = someString.Equals(otherString, </font><font color="#008080" size="4">StringComparison</font><font size="4">.InvariantCultureIgnoreCase);</font>

    <font size="2">The StringComparison enumeration has other five values you can pick, two of them also involve ignoring case.</font>

    [/quote]

    This code should throw an IHateDotNETBecauseOfTheRidiculouslyLongIdentifiersException.  That one .NET college project I did was hellish.  Good thing I haven't had to touch it since.
     



  • [quote user="Renan "C#" Sousa"]

    <font color="#0000ff" size="4">bool</font><font size="4"> equality = someString.Equals(otherString, </font><font color="#008080" size="4">StringComparison</font><font size="4">.InvariantCultureIgnoreCase);</font>


    [/quote]

    Does anybody else find this identifier hilarious? I particularly like how they've managed to take 43 characters to describe one of the most common operations.



  • @vt_mruhlin said:

    This code should throw an IHateDotNETBecauseOfTheRidiculouslyLongIdentifiersException.  That one .NET college project I did was hellish.  Good thing I haven't had to touch it since.

    I assume you never learned typewriting and you had to use notepad to write the code. 



  • @asuffield said:

    [quote user="Renan "C#" Sousa"]

    <font color="#0000ff" size="4">bool</font><font size="4"> equality = someString.Equals(otherString, </font><font color="#008080" size="4">StringComparison</font><font size="4">.InvariantCultureIgnoreCase);</font>

    Does anybody else find this identifier hilarious? I particularly like how they've managed to take 43 characters to describe one of the most common operations.

    [/quote]

    Not to mention it took them more than four years to supply it (in NET 2.0). Before that you had to resort to someString.ToLower() == otherString.ToLower() or other inefficient tricks.



  • @asuffield said:

    [quote user="Renan "C#" Sousa"]

    <font color="#0000ff" size="4">bool</font><font size="4"> equality = someString.Equals(otherString, </font><font color="#008080" size="4">StringComparison</font><font size="4">.InvariantCultureIgnoreCase);</font>

    Does anybody else find this identifier hilarious? I particularly like how they've managed to take 43 characters to describe one of the most common operations.

    [/quote]

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.



  • @Random832 said:

    @asuffield said:
    [quote user="Renan "C#" Sousa"]

    <font color="#0000ff" size="4">bool</font><font size="4"> equality = someString.Equals(otherString, </font><font color="#008080" size="4">StringComparison</font><font size="4">.InvariantCultureIgnoreCase);</font>

    Does anybody else find this identifier hilarious? I particularly like how they've managed to take 43 characters to describe one of the most common operations.

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.

    [/quote]

    The current locale setting is just for the user interface. It's invalid for data received on any other path, including but not limited to disk and network access. Since Microsoft's solution to the locale-dependent-data storage problem is "break like a bitch", the only option is to fall back on the natural semantics of the character set.



  • @asuffield said:

    @Random832 said:
    @asuffield said:
    [quote user="Renan "C#" Sousa"]

    <font color="#0000ff" size="4">bool</font><font size="4"> equality = someString.Equals(otherString, </font><font color="#008080" size="4">StringComparison</font><font size="4">.InvariantCultureIgnoreCase);</font>

    Does anybody else find this identifier hilarious? I particularly like how they've managed to take 43 characters to describe one of the most common operations.

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.

    The current locale setting is just for the user interface. It's invalid for data received on any other path, including but not limited to disk and network access. Since Microsoft's solution to the locale-dependent-data storage problem is "break like a bitch", the only option is to fall back on the natural semantics of the character set.

    [/quote]

    And in what universe do those semantics involve case-insensitivity? In other words - even if it's not the current locale setting, when are strings you want to compare case-insensitively NOT in some natural language that you will want to do an appropriate locale-specific comparison for? (And, regardless of disk and network access; once it's in memory and in a String, it's in UTF-16, so the only locale issues to deal with are language semantics, not codepages.)
     



  • @Random832 said:

    when are strings you want to compare case-insensitively NOT in some natural language that you will want to do an appropriate locale-specific comparison for?

    When you don't know what language they're supposed to be in. 



  • @Random832 said:

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.

    Surely that would be any situation where you know the language of the data being read and don't want, say, Turkish alphabet rules applied to your English data?

    To be honest it strikes me as odd that there's no shorter way to do such a common operation, though admittedly I'm used to brevity at the expense of comprehendability:

    bool equality = stricmp(someString, otherString); 

     

    edit: Stupid C >_< 

    bool equality = stricmp(someString, otherString)==0; 



  • @Devi said:

    @Random832 said:

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.

    Surely that would be any situation where you know the language of the data being read and don't want, say, Turkish alphabet rules applied to your English data?

    To be honest it strikes me as odd that there's no shorter way to do such a common operation, though admittedly I'm used to brevity at the expense of comprehendability:

    bool equality = stricmp(someString, otherString); 

     

    edit: Stupid C >_< 

    bool equality = !stricmp(someString, otherString); 

    fixed that for you 



  • @Devi said:

    @Random832 said:

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.

    Surely that would be any situation where you know the language of the data being read and don't want, say, Turkish alphabet rules applied to your English data?

    Then won't you want ENGLISH rules applied to it? I can't think of any especially common circumstance where you'd want case-insensitive rules that you would also want InvariantCulture rules. Replace "current language setting" with "a language setting" in my original statement.

    About the only time it would be needed would be for parsing machine-readable languages that are defined as case-insensitive with a particular mapping that happens to exactly match what InvariantCulture does.



  • @Random832 said:

    @Devi said:
    @Random832 said:

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.

    Surely that would be any situation where you know the language of the data being read and don't want, say, Turkish alphabet rules applied to your English data?

    Then won't you want ENGLISH rules applied to it? I can't think of any especially common circumstance where you'd want case-insensitive rules that you would also want InvariantCulture rules. Replace "current language setting" with "a language setting" in my original statement.

    About the only time it would be needed would be for parsing machine-readable languages that are defined as case-insensitive with a particular mapping that happens to exactly match what InvariantCulture does.

    You have a text file. Like everything else on a Windows system, you have no clue what language settings were used by the user who wrote it. What rules are you going to use to process it? 



  • @Random832 said:

    Then won't you want ENGLISH rules applied to it? I can't think of any especially common circumstance where you'd want case-insensitive rules that you would also want InvariantCulture rules. Replace "current language setting" with "a language setting" in my original statement.

    According to MSDN ([url]http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo.invariantculture.aspx[/url]) selecting InvarientCulture will give me English rules though. I'm not a .NET programmer, but I get the impression that InvariantCulture is the localization setting you would use for processing almost all machine generated text, for example data passed in HTTP requests or stored as part of a browser's configuration settings.

    Obviously you want "a language setting" when doing string operations, but in this case doesn't the InvariantCulture count as a language setting?

     



  • @asuffield said:

    @Random832 said:
    @Devi said:
    @Random832 said:

    One of the most common? How often do you really want to do a case-insensitive comparison that's NOT dependent on the current language setting (and therefore matches "i" with "I" which you don't want in turkish, etc) - the situations I can think of that you would want to use the invariant culture are mostly ones where you would also want to be case-sensitive.

    Surely that would be any situation where you know the language of the data being read and don't want, say, Turkish alphabet rules applied to your English data?

    Then won't you want ENGLISH rules applied to it? I can't think of any especially common circumstance where you'd want case-insensitive rules that you would also want InvariantCulture rules. Replace "current language setting" with "a language setting" in my original statement.

    About the only time it would be needed would be for parsing machine-readable languages that are defined as case-insensitive with a particular mapping that happens to exactly match what InvariantCulture does.

    You have a text file. Like everything else on a Windows system, you have no clue what language settings were used by the user who wrote it. What rules are you going to use to process it? 

    Case-sensitive ones. Upper/lowercase mapping is language-specific, so it doesn't make sense to use case insensitivity on a file that I don't know (or assume) what language it's in.
     



  • Why are you processing text files you know nothing about?



  • @Salami said:

    Why are you processing text files you know nothing about?

    Probably because you're on a Windows system and hence have no information stored about them. Microsoft have declined to attempt to solve the locale-dependent-storage problem. 



  • @asuffield said:

    @Salami said:

    Why are you processing text files you know nothing about?

    Probably because you're on a Windows system and hence have no information stored about them. Microsoft have declined to attempt to solve the locale-dependent-storage problem. 

    The point is, you have to know or assume something about files to do any kind of processing at all. Whether it's stored with the file (maybe because since we're talking about string processing, not text files, you've stored them in a binary format and put the locale information there yourself), guessed heuristically, or prompted for the user to pick, you do ultimately have to choose what locale to treat the file as. 



  • @Random832 said:

    @asuffield said:

    @Salami said:

    Why are you processing text files you know nothing about?

    Probably because you're on a Windows system and hence have no information stored about them. Microsoft have declined to attempt to solve the locale-dependent-storage problem. 

    The point is, you have to know or assume something about files to do any kind of processing at all. Whether it's stored with the file (maybe because since we're talking about string processing, not text files, you've stored them in a binary format and put the locale information there yourself), guessed heuristically, or prompted for the user to pick, you do ultimately have to choose what locale to treat the file as. 

    And most of the time, C/ASCII is the right choice for blind files.



  • @asuffield said:

    @Random832 said:
    @asuffield said:

    @Salami said:

    Why are you processing text files you know nothing about?

    Probably because you're on a Windows system and hence have no information stored about them. Microsoft have declined to attempt to solve the locale-dependent-storage problem. 

    The point is, you have to know or assume something about files to do any kind of processing at all. Whether it's stored with the file (maybe because since we're talking about string processing, not text files, you've stored them in a binary format and put the locale information there yourself), guessed heuristically, or prompted for the user to pick, you do ultimately have to choose what locale to treat the file as. 

    And most of the time, C/ASCII is the right choice for blind files.

    You keep coming back to the "neutral locale" thing, but you're totally ignoring my other point - if you don't know or care what language something is in, why are you doing case-insensitive processing? (and we're talking about Strings, which are always UTF-16 no matter how they got there, so by this point the encoding of the file has been dealt with, with either success or failure but anyway you have a string that you think represents the data that was in the file)



  • @Random832 said:

    You keep coming back to the "neutral locale" thing, but you're totally ignoring my other point - if you don't know or care what language something is in, why are you doing case-insensitive processing?

    Why on earth shouldn't you? We had case-insensitive applications about twenty years before people started bitching about how there was a banana republic in a swamp on a mountain someplace that thought Q was the uppercase form of z.

    The introduction of more complete locale support is not an excuse to break something that has been working since we moved away from punched cards. It is completely ludicrous to even suggest.

     

    (and we're talking about Strings, which are always UTF-16 no matter how they got there, so by this point the encoding of the file has been dealt with, with either success or failure but anyway you have a string that you think represents the data that was in the file)

    Encoding is entirely unrelated. Unicode carefully and laboriously refuses to even attempt to solve this problem.


Log in to reply