Loved by Lawyers and DHS Agents alike!
I got angry long ago at parsers that pull these stunts, which is why the utilities.DLL for the compiler has its item() method, which parses strings based on delimiters. In this case, it would return the space, but elsewhere in the code you will see a lot of Trim(Ucase) statements...in which I consciously normalize keywords. Of course, this is doable if you are the Lone Ranger with no Tonto about the shop who doesn't know ALL your mental conventions, which is why the utilities.DLL contains so many routines...each is a "reification", a gesture that makes a concept into a thing. The utilities library, while it has been used by several employers and clients to get real work done, has also annoyed others. They sense as did Theodore Wiesengrund Adorno (the verbose German theorist of the last century who wrote the almost unreadable book Aesthetic Theory) that a work of art is that which is a protest against the everyday. Code can actually in my experience be perceived, especially by hardworking programmers, as snooty, blue-state, wine and cheese eating, and supercilious. I believe many programmers code "defensively", in the sense of making their code ugly, in order to avoid being accused, by their manager or coworkers, of a great sin, and that's wasting time that is no longer yours, but that you've already sold. A consultant buddy in San Francisco had to write a file manager for an embedded system. He was all happy because he persuaded the manager that all files could be restricted to 512 bytes. I said it might actually be easier to ALLOW variable length and build a link list of variable sized segments...since he was gonna build a link list anyway, but he seemed convinced that a "hard and fast" restriction (similar to the one you encountered in Config files) would make his life easier. He might be right, for I have worked long into the night trying to noodge a partial solution, which meets the client's "needs", into something Better. I think the difference is he doesn't like to code. My concept here is that "keywords, which the user might enter in a Config file, are entered in haste, and should be parsed and then normalized into a limited language, in which all words contain letters and numbers, and in which there is no case". However, this is at best not even a vision, just the conclusions of a superannuated geek. I need to either put them in rhyming form, and teach them to a cult on the West Coast where they think I yam a guru, or develop a programming language, or just continue to Code and be damned. Programming Fundamentalism is the very idea that there is One Great Programmer, somewhere, who writes perfect code in the ideal language when in fact what there are are coders who at best humbly respect the conventions of the Other, and who don't break those conventions. Or arrogantly, in the case of Config files, don't impose their limitations on others. I'm thinking of the stunt Microsoft pulled with Visual Studio 2003 because as far as I can see, the only REAL change was to separate lines in text files in Web style, with a single linefeed. This stunt had me adding a utility to detect the style (based on the first 1024 characters of the file considered as a string) and return it to the caller. All the same, I need to upgrade back to 2003. My copy on my laptop was smoked, fortunately after I finished the Apress book, and I am using 2002. Should I wait for Whidbey?
I'm with you 100% on this Edward - I really don't understand the fussiness of it. Even playing Devil's advocate - I don't see the value. For instance, I had the following: <wellknown mode="Singleton" type="SomeNameSpace.BusinessDALC , KDNBusinessDALC" objectUri="BusinessDALC.soap"/> Now, the space was in between the end of the class name and the comma that separated it from the assembly. Now, if for some reason you decided to be an a33hole, I mean creative, and start appending spaces on the end of your class names - well, they'll be ignored if you do it in the editor. If you do it in the dialog box, the class get an _ appended to it. Either way that space will not be recognized. As such, this part of the config section should be smart enough to pick that up or there should be warnings everywhere. Why? Well, because it's not that hard to imagine someone who is anal about organizing their code might put a space after the class name and after the comma. In the second instance, the Space before the assemblyname is not assumed to intentional and is ignored. so if that's ignored, it's not really that crazy of an assumption to think that the first one will be ignored too. but it's not. I might be talking out of my a33 here, but I can't see one grammatically sound reason for this. Moreoever, let's say that there is one. Why not have a specific exception thrown - WhiteSpacePresentInWellKnownTypeDeclarationException (or NoWhiteSpaceAllowedException to keep things concise). If some dumb a33 like me can parse that and find a whitespace certainly it's not that hard. Then there's the <appSettings> tag. <appSettings> works like a charm but <AppSettings> doesn't. I understand the case sensitivity thing and all of that, but perhaps you could implement this. If someone is trying to access appSettings and AppSettings is found but appSettings isn't, assume that's what they meant to do. No, I'm not advocating that you scrap the case sensitivity thing, but crap- how hard would it be to put a switch in there to turn off or on "Case Sensitive Keywords"? I can't for the life of me see why that's not an option because, well, having a method named 'main' that isn't Main - is just asking for confusion. It's too easy to overlook something like that (not with Main per se, but things that are obvious keywords) when you're looking at it because the first thing that crosses your mind is that something is broken and that's why it's not working - not that you forgot to capitalize something. You can't make this same mistake in the IDE because it will throw a compile error And even assuming that you wanted to be so flexible that class names that end in spaces is something you see as a good thing - at least let people shut it off. How much VB code have you looked at from people that were having issues with it, only to see that Option Explicit wasn't on and they misspelled it? If I'm writing in VB.NET - you damn well know I'm using Option Explicit because it's too f**** easy to make a typo and trying to figure it out is a total waste of time if it can be avoided by setting a flag on. People are by definition, human. People get tired especially when they've been staring at a screen for 12 hours. Stuff like this kills productivity and I've made the AppSettings mistake at least twice. Another one is the conditional Attribute. [Conditional("Debug")] and <Conditional("Debug")> _ should both accept ("DEBUG") to be honest, I think it's C# that will bust you on this . But if you don't put a space between the end of the > _ then you'll get an Identifier expected error. Since I can't use the >_ as a legit way to deal with attributes - why have it? I know, I'm being petty but this is so trivial and so easy to overlook when you're Remoting stuff on a dual processor machine that it's really annoying to find out that's all it is.