in reply to cleaner code ....

Yes, what you have is already pretty clean. So here's some thoughts and suggestions, anyways.

I suggest you take this code and shove it down into a subroutine. See Ovid's post Linear programming is bad for why — mainly that it allows you (and maintainers who follow you) to see the toplevel flow without sweating the details. You'll have a decision to make. You can either implement a general &split_record_into_arrays function or a more specific &split_into_city_county_state. The former is cleaner and more general. The latter gives more opportunity for validating your data. E.g., making sure that every state really is a legal state.

Perhaps this is just a class assignment and the point is to learn how to manipulate data structures. But if this is a real app, why to you want to apply 'uniq' to a list of cities? Why would you want to have just one city-entry for Springfield, Maine and Springfield, Ohio? And then why wouldn't you want to combine Akron and AKRON?. Right now, if you have a record with only two fields, you put an undef in the last list; is that OK? And you don't detect records with four fields.

throop