Actually, there is, and I found it using a variation on one of the suggestions above (thanks, folks!): [^]

My laptop is used strictly on trips as a portable substitute for my desktop, so it gets powered up and down each time I use it. However, my company makes products that are based on Windows CE (6.0, in our case), and that OS has counters involved in timing that overflow about every 49 days, so our User Manual recommends power cycling the unit at least once a month. If the software is written correctly, that overflow can be handled, but I learned years ago to assume that software is never written correctly.

A recent thread in this forum complained that a particular issue was "ungoogleable" because of the vagueness of the words involved. This reminded me of a song I played in high school pep band that I tried to Google a while back and couldn't figure out how. The song title was ["A" Rock] (without the square brackets - I added them as pseudo-quotes because the double quotes ARE part of the title). When I try to Google this, Google ignores the quotes, discards the "A" as an article adjective, and simply returns results for "rock" (which of course give me millions of results unrelated to this song). Any suggestions as to how I might find information about this song, if such even exists?

I refer to myself as a "software janitor." All I do is follow other people ("code monkeys"?) around and clean up after them.

My experience has been that the "normal" 5x8 tends to turn into 5x10 anyway (or 4x8 + 1x24, or 5xuntil-you-can't-see-straight, or something like that). Point is, once I'm "in the zone," I tend to want to keep going as long as I can, rather than stop at a particular point on the clock and have to reboot my brain the next morning. Plus, with all the typical interruptions during business hours, I often don't really start being productive until 4 or 5pm anyway. Having three days a week off would almost have to be a positive.

Yeah, I know. But it's about the only job available in my relatively small city, and I'm nearing retirement anyway, so I'm basically just playing out the clock...

Good to know that named parameters were actually implemented. At my job, we're still using VS 2008, so I wasn't aware that they had taken my advice!

Nobody seems to have yet mentioned any other alternatives...one would be passing in a structure with 24 members as an initializer, although in C# that doesn't really eliminate the problem, since you'd have a similar problem with how to initialize the structure. Might be useful tho if you instantiated a lot of these objects with mostly the same parameters. I would never condone instantiating a class without initializing all member data items, but if there are reasonable default values for them, I could see an initializer (or maybe even a few) that initialized all or most of them to default values, and only set one or two to non-default values. Don't ever want to leave values uninitialized, however. Of course, there are those who would say that any object that needs this many initializers is poorly designed and should be refactored. It would be up to the author in each individual case to decide if this is feasible. For my money, this makes a good case for a language feature I've been wanting ever since the days I worked with the ADA language - named parameter lists. Then you could offer default values for all parameters, and let the caller set only the ones (s)he wants to differ from the default values. Of course, you can emulate this now in C#, but it requires 2^n constructors. I've done it with three parameters (eight constructors), but of course it would be impractical with 24.

Yeah, I've always been a little ... Oh, look, an SQL!

I always pronounce "SQL" as "squirrel," but that's just me.

I've been maintaining a C++ codebase for several years now that has this type of thing all through it:

if (someErrorCondition)
{
char *msg = "Error 404\n";
char s[100];
sprintf(s, "%s", msg);
PrintErrorMessage(s);
}

as opposed to just:

if (someErrorCondition)
PrintErrorMessage("Error 404\n");

And this was in an embedded system, where they were constantly having to eliminate features because they had exceeded the limited code space or overflowed the stack!