Daniel Stallard wrote:I'm sorry that my code is messy.
That is bad for you, not for me, so no worries
Daniel Stallard wrote:I'm no very familiar with using maps and it seems pretty complicated to get a random key.
It isn't about the map. It is about the environment where you fiddling with those maps. Everything around is messy.
As a real life example, imagine for a moment surgeon's scalpel, in your case it is a Map, but have you ever had a chance to see how the things are organised in a surgery room?
[1] Everything have their precise place
[2] All the time they are in the same place
[3] There are no unnecessary things
That is all about that.
Now think if everything would be like in a
flea market, I think you wouldn't like even to think about the idea in having any kind of business with such surgery room.
Program's organisation and slight pedanticism isn't something you need to study for years in order to learn. I think this is something you can pick up right away and help yourself a lot.
All the comments you wrote - they add extra noise and disturb you from seeing actual code.
Example of useless comment you wrote:
As you see it adds absolutely no extra information to what actual code line tells you. So why to add it?
However, in your code there is only one comment which in my opinion is quite useful:
What it tells me as a reader, that it is your intention to do nothing after you catch the exception at line 67. If such comment wasn't there, I'd think you might forgot to add handling part. As an improvement of this comment you could write why there is an empty handling part.
So, only by removing all useless comments, your program would look way better. That's one.
Second. Variable names.
As you see, you trade in clarity for saving the keystroke - that's a bad idea.
You should pay attention to clarity, always. Imagine you have a big project and you are discussing with your fellow colleague about the code snippet where state capitals are handled. So you ask him to have a look. How one could know how to find that part? In
IDE's there are tools to look up for text match within a project, and if you were name it stateCapital or other sensible name which you use in spoken language with your fellow colleague, that would be very easy for him/her to find it. You don't tell him about the code, look, there is a problem with sta cap map. What?!? I mean there is a problem with state capital... Oh, this is what you mean... So why not to use clear, unambiguous names?
Third. Methods.
One of your methods is 50 lines long. I have in mind
readText(). You could break it down slightly, so you'd have 2 or 3 methods out of this 1. The good part about breaking down problem into smaller problems is, that if you know that there is a problem in adding capitals to some kind of data structure, you are worrying only about the method (small), which is responsible for that, rather than searching through all 50 lines and thinking if there are no overlapping logic or similar. Deal with small things is always easier than with bigger. Unless you are aiming with a bow at target
I'm not forcing or giving you a pressure, but just think it through, you might will find some ideas useful.