It would be a bad practice, because it introduces a dependency on a subtle assumption that is hard to document and hard to remember accurately: namely, that the values maintained in this place are any strings without spaces in them. This is almost the same as "any strings", and the former definition will inevitably be mistaken for the latter one day.
Configuration values like these will almost certainly have to change as a system develops. Storing them this way will work fine until one day, new data violate the unspoken assumption and introduce a defect. Note that the defect will probably be subtle: values before the string with the space in it will still be processed correctly, and the ones afterwards will appear in slightly the wrong position, only the value itself will be missing and two or more others will take its place.
In a way, subtle preconditions and subtle defects like this are much worse than obvious ones. Glaring errors are noticed quickly and eradicated quickly. A misbehaviour like this is liable to go unnoticed for quite some time and do damage that won't immediately be known, until it can't be easily repaired and the cause can't be easily found because the programmer who constructed the storage method has moved on.
(What, then, should one do to store large numbers of string literals? Unless your language has a quote-less construct like Lisp lists or Perl's
qw() operator, you are almost certainly better off holding string values in a properties file or a database than spelling them out in code. There are other reasons why this is a good idea, but avoiding methods that are either hard to read or subtly problematic is reason enough.)