Regarding whether or not arrayToString() is a Good Thing will really depend upon your programming needs. I would think carefully about using it because, essentially, you're throwing away information (the warning, in this case). Part of the standards that I have developed for my work state "all production code must run without warnings unless preapproved by the project lead".

Precisely why I asked. I'm more than aware that warnings and other messages are designed to let you know that there might be a better way to do things, one that doesn't generate the message. That's why I asked. My routine doesn't generate the warning, so I presumed it was a more appropriate solution. Would a different approach be better?

I like your rewrites, but humbly submit that the different naming conventions are more of a stylistic convention rather than an idiomatic one. As far as I can tell, the underscore separation seems to be preferred by *nix folks while Windows folks appear to prefer the camelCap convention. Now, I know that perlstyle submits:

While short identifiers like $gotit are probably ok, use underscores to separate words. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.

I personally disagree with it, just as I disagree that the following is easier to read:

if (condition){
   &task1();
   &task2();
   &task3();
} else {
   &task4();
   &task5();
   }
[download]

Than this:

if ( condition )
   {
      task1();
      task2();
      task3();
   } 
else 
   {
      task4();
      task5();
   }
[download]

Now, many folks will disagree with me on that. That's fine. As long as we're each consistent in how we do things, I don't see there's much reason to quibble over presentation.¹

Remember: coding standards need to be flexible enough to evolve as the team does. They should not turn into straight-jackets that cannot adapt to new ideas or allow the programmer a little bit of creativity. Each programmer has a set of personal preferences and the wise standards-keeper will find ways of allowing each programmer to bring their skills and ideas to the table. Otherwise, you risk dissension because the programmer spends more time fitting (and frequently griping) into your vision of what good code looks like.²

Getting back on track. I suppose a more relevant question might be: OK, you've generated a warning. Now what? (Me? I write a subroutine that tests for the condition the warning is trying to alert you to and then responds accordingly.)

--f

¹ - TIMTOWTDI

² - I once got marked down on a performance review because (in a different language that used IF..ENDIF as block keywords), I accidentally wrote: If ... EndIf, instead of the "standard" if...endIf. As you might guess, I'm a bit...uh...passionate in this point. And, yes, that was enough to adversely impact my increase that year. (As you might expect, I quit shortly thereafter.)