##Leap My code: here
-
Responder #1 (here) - This responder took largely the same approach as me but used the "if/return true" approach rather than the single line return method. In this case I feel the one-line method is sufficiently clear and therefore would probably be preferred over using if/return.
-
Responder #2 (here) - This user employed an even more broken-out approach than the first responder, creating a three part "if - else if - else" conditional. For the same reason as #1 I feel that the one-line approach would be preferred in this case.
-
Responder #3 (here) - This user decided to build the logic out with a nested conditional, nesting the %100 and %400 checks within the %4 conditional. It appears cleaner at first glance and the nested structure does mirror the logic of the problem, though I know in a more complex situation a nested conditional could prove to be a real can of worms.
-
Responder #4 (here) - This responder took a similar approach to the first two, using an if/else statement and issuing four different returns of true or false. Once again, in a simple case such as this, letting the and/or operators in javascript return their natural true/false values would probably be a shorter and more effective solution.
-
Responder #5 (here) - The final responder used an interesting combination of my "and/or" approach and the more common "if/else" approach, wrapping the %100 || %400 portion under a conditional to check whether %4 is true. This feels cleaner than the pure "if/else" approach, though it seems strange to use an "or" operator along with an if statement and I feel it might be best to simply pick one approach or the other.
##Hamming My code: here
-
Responder #1 (here) - This first response immediately shows me that I could have streamlined my code better. I waste time splitting strings and mapping an input when it turns out neither are required. The responder solution is the superior solution in this case.
-
Responder #2 (here) - At first glance this response seemed to be very similar to my own, but there is one major difference. While this responder sets a boolean on whether the respective length of the strings match and throws the appropriate error if necessary (same as my approach), it uses an advanced reduce function to increment the difference count. Overall I would say the solution is clean and in terms of clarity and efficiency supercedes my own.
-
Responder #3 (here) - This approach uses the same startegy as most of the previous in terms of identifying and recording errors, but is clever in terms of the way in which it increments the vote count by using substrings. Overall I would say more effective (and more clever) than my approach.
-
Responder #4 (here) - This user's approach, while similar to that of the prior user, appears to be the cleanest and (for me) easiest-to-understand. It also confirms that the meat of this function can be taken care of with one "for loop" and one "if loop" if necessary.
-
Responder #5 (here) - The final solution does much of what the other solutions have done except it both splits and reduces the strands and counts at the beginning of the function and then later calls on the function to execute that piece of code.
##RNA Transcription My code: here
-
Responder #1 (here) - The first responder appears to have been given tests for both toRna() and toDna(), while mine focuses on toRna() only. Regardless, this approach does a great job of reusing the convert() function for both types of translation.
-
Responder #2 (here) - This approach is essentially identical to my own; the only difference is that I had to manually replace excess commas in the result with RegEx while it appears this solution did not have to do that.
-
Responder #3 (here) - This response accomplishes what the two previous responses did but manages to simplify, clarify, and shorten the necessary logic by using chaining. While I set variables for the old characters and new characters, this response splits, maps, returns values, and reforms into a string all within one function. For a simple problem, a clear and fast solution like this should be sufficient.
-
Responder #4 (here) - The fourth response here may be the most sophisticated. It uses underscore to execute the reduce, split, and return all within 3 lines of code. This approach still involves setting a blank string object that later has the return RNA value appended unto itself.
-
Responder #5 (here) - This final response is by far the longest of the five considered here. On one hand, the responder uses a module to hold the functions for translating, which looks good. On the other hand, the responder creates a new object (new_obj) that doesn't need to be independently created. The responder also does not need a separate function (splitStrandToArray()) for split/parse of a string when it could easily be handled in a single line.