This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
D.J. Quavern wrote:. . . Junilu said once "main is a pain", is it why?
No, it was Wnston Gutkowski who said that.
1: Because it is static, so use of the main method means you are not working in the object‑orientated paradigm.
2: Because it is a void method, which means you cannot use it as a function and can't use it is a functional paradigm.
3: Because lots of code in a method make it difficult to follow and difficult to maintain or update.
Should I made helper functions?
You already have helper functions, in this case the utility class' methods which you are using for input. I think no; I think you should write the code in a object‑oriented fashion, so you have a Message class with one instance for each of your 10 messages, with the array of arrays as a field. It would need getEncoded() and getPlain(() methods, though you can probably use the toString() method for one of those. Or you could use PlainMessage and EncodedMessage classes with one method each. That would be the object‑oriented way to solve your problem, even though Kattis might only be looking at results and timings.
Why ave you called a char something like doubleArray? That is a confusing name. Maybe lettersMatrix or similar would be better.
How can I make it faster or more efficient? . . .
The only way I can think of making it faster is to remove the multiple print() instructions. Don't print individual characters; append them to a StringBuilder object and print the whole StringBuilder out. Even so, I am surprised to find you exceeding 1′ for something straightforward llke this exercise.
Up to 100 strings to decode that can be up to 10K characters long each.
Not surprised. I think the StringBuilder can help a bit but two sets of nested loops is not necessary. You can cut down time by half what it is now by changing your approach and using only one nested loop.
I have to admit, I learned something about I/O today. I switched to Kattio for I/O and got 0.19s (down from 0.29s with Scanner and System.out.println).
Some things to note:
1. Got the same performance number even when doing I/O after every line decoded instead of just once at the end.
2. The variable names I used. I found the variable names you used confusing. I used terms that come from the domain: "cipher text" and "plain text"
3. Admittedly, your code helped me clean up mine a little. Previously, I was doing a little bit more arithmetic with the loop indices. So I stole two things from you: the I/O and the cleaner loop index management.
Keeping decode() a separate method allowed me to write a unit test for it:
Having a unit test like this while I was working through the logic and cleaning it up really helps make yourmy life easier and development faster. It makes your life better if you had to come in and make more improvements to my code.
I wonder if the difference of 0.1s has more to do with the sheer size of Scanner rather than its actual performance characteristics. Relatively, it's much larger than Kattio. Should be an interesting exercise to find out just where the performance gains are for Kattio.