I prefer to use names that contain umlauts[^] over each vowel. Reading it is a bitch, and typing it is much harder, but it's my own style, and I like that. It's important, I think, to express one's individuality in the workplace.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Just use shorter identifiers. I've started to use namespaces a lot for that reason. I use a notation that looks like this: IO::Backup::Database(...). My apologies if namespaces aren't available in your toolset.
Personally, I prefer camel case over underscores in long identifiers.
The main problem in you examples is not the case, but the lenght of the function. GetMyXML() is not difficult to read at all. If you function or variable names are that long, you might need to split the functionality into smaller parts.
Back in the mainframe days, before PCs were invented, underscores were a standard way of making long identifiers readable.
As people have observed, it's slightly more effort to type, but code is only written once and read many times. More effort and expense per line of code is expended in maintenance than initially creating it, so if it makes your code more readable it may be worth it.
I have always used Camel Case because it is easy to read. I hate reaching for the underscore anyhow. Give me the main three rows of keys for ease of typing. Anyhow it is part of the accepted coding conditions for VB programming.
The best thing would be for everyone to follow the accepted coding conventions for the language they are using. Sure makes it a whole lot easier when you have to take over an existing project if the previous programmer did use the coding conventions. I have re-written enough apps in my time because the orginal or previous programmer didn't follow them and it took me extra time to decode.
To the OP: agreed, in general. But for small variable names, camelCasing is definitely easier and doesn't exact too harsh a reading penalty. The difficulty in reading grows with each word added, so if you can keep your names to two-three individual components, you should be all right. By contrast, sticking in a bunch of underscores can seriously extend the length of a variable name, which I begin to find just about as onerous as reading scrunched names.
So, my advice is to use underscores if you really need them, but be as sparing as possible. (Hint: they do make a great way to abbreviate certain groups, such as "to", "of the", and other article conglomerations.)