My code: here
Responder #1 (here) - This responder used a long case statement for flow control instead of the key object that I used. In ruby, I think my solution is cleaner, but I don't know enough about javascript style to say what's better here. I often find myself thinking of the ruby solution first and then trying to write it in javascript.
Responder #2 (here) - Jon also used if/else if/else for flow control but used a syntax I'm not familiar with- didn't use curly brackets around the code to run when conditions returned true.
Responder #3 (here) - Alex's solution is a lot like mine, but he has organized the code differently- he defines the toRNA function on 'this', instead of on a prototype, as I did. He also splits the string into an array of chars before performing the work, then joins the characters back into a sting at the end- that's what you'd do in ruby, but in javascript you can do that stuff directly on the string.
Responder #4 (here) - Here's one that's really different, and I'm not completely sure what's going on with the hashrockets, but it looks like he is mapping over the chars as an array, returning the replacement letter form his key. Then, maybe the reduce is a fancy way of joining? Does the hashrocket mean 'return'? if so, what's it doing on line 10?
Responder #5 (here) - This one's similar to mine, but instead of building a new string, the responder is replacing each letter in the old string with the correct RNA letter. This makes for less lines of code but I wonder if the solution would be more brittle against edge cases not tested here.
My code: here
Responder #1 (here) - Ashwin's solution is functionally like mine, but he has broken the work into 2 functions, and he as assigned the input- an array of 2 things, to two variables. This is more verbose but I think more readable than mine.
Responder #2 (here) - This responder checks if an error should be thrown first, and in this way, the code is more explicit as to why the error is thrown. On the other hand, I have always heard that one should try to assert a positive rather than a negative, so I don't know which is better.
Responder #3 (here) - This responder first just checks if the two inputs are equal- this seems unnecessary since the for loop will also return zero if the 2 strands are the same, but maybe this function is faster if it were to be performed A LOT and many of the inputs were the same?
Responder #4 (here) - This responder is using a different approach- he has zipped the two arrays together, and checks if there are any null elements in the pairs to throw his error. He uses a reduce to count the differences between the pairs.
Responder #5 (here) - Patrick has also broken the solution into 2 functions, but he uses underscore's reduce to compare the strands.
My code: here- note: my solution still has one test failing, but it was driving me SO crazy that I just had to see other peoples implementations. Plus, everyone's Leap is the same- boring.
Responder #1 (here) - Brenna's solution is very like mine, but I like how she has organized the code so that the main event is at the top and helper functions are below. Each helper is very similar in structure and syntax so the solution is elegant and easy to read.
Responder #2 (here) - This responder's solution to testing for 'silence' is SO much simpler than mine. It simply trims the sting of whitespace and then compares it to an empty string, whereas mine tests each character of the string individually.
Responder #3 (here) - This responder uses Regexp for all of his tests against the content of the string, which makes his functions very uniform. Do people eventually memorize all of the symbols in Regexp? If no, one would aways need a reference handy to read this code- a downside.
Responder #4 (here) - This response shows an even easier way of checking for silence- an empty string is false. Apparently a string containing only whitespace is false too. Weird!
Responder #5 (here) - This responder has organized the code in a different way- The possible responses are stored at the top as an object, helper methods come next, while the main event is at the bottom, accessing the responses by calling properties of the responses object. Neat!