Ad
  • Custom User Avatar

    solution will be improved if you add "i < (arr1.length < arr2.length? arr2.length : arr1.length);" to for loop, that way if one array is longer, it will consider the longer one's length ,

  • Custom User Avatar
  • Default User Avatar

    Nice function, took it

  • Custom User Avatar

    "Given a number n, return the number of positive odd numbers below n, EASY!"

  • Custom User Avatar

    And is correct that way because inputs "... are always lowercase strings, and that each has at least two letters.". If that was not the case and arbitrary inputs would be allowed we'd also need checks for null and lengths in order to avoid NullPointerException and IndexOutOfBoundsException or alike.

  • Default User Avatar

    it work only if cases are equal

  • Default User Avatar

    I would rather have more spaces to increase the readability of the code, but it's okay

  • Default User Avatar

    Thank you a lot for the explanation and providing this article, I'l read more about OOP for sure

  • Default User Avatar

    It's not like it's better to use "static". You use static keyword when you want to call method or variable without creating class instantiation. In this example I just want to call method so I skipped creation of new Kata object. I suggest you read some about object oriented programmin, you will fully understand purpose of this keyword 😇 Anyway there is cool article about "static" keyword:
    https://www.baeldung.com/java-static

  • Default User Avatar

    is it better practice to have static keyword in it?

  • Custom User Avatar

    I did it using a DFA and it was wayyy longer. How do you get it to be this short?

  • Default User Avatar

    To begin with, I didn't tell that any method must have exactly one return statement.
    For maintainability reasons method has to have AS FEWER RETURN STATEMENTS as possible.

    'Object.equals() method uses multiple return statements'

    equals method in the Object class has only one line that checks reference equality. Basically, it is entry-level information that you should know by hard.
    Most of the classes in the JDK and different frameworks override default implementations of the equals method to define equality based on an object's state.

    For the purpose of explanation, I think equals probably is not the best illustration because it is short and simple.
    To describe a method that has more than one exit point but still remains to be well-readable let's consider a method, which implements some intricate algorithm, and may be it's a relatively long one. And it has the following structure:
    {
    if (eliminate one case) throw ... // that's the early kill and that's great
    if (eliminate another case) retrurn ... // and that's the early kill as well

    // MAIN LOGIC

    return ...
    }

    To conclude, in general, return statements in the middle of a method has to be avoided where it's possible.
    Because it can create confusion when return inclosed by multiple loops and conditions, as well as when return statements are present in both try and catch blocks.

    DISCLAIMER: I don't say no one writes like that. I say it is considered to be undesirable nowadays.

    Quick digression. If you think that JDK is written by the Gods and there are no pitfalls in Java you have a lot to discover.

    'how you would solve problems of that kind in general'
    In terms of clean coding, it's a naive way of thinking that there's some kind of uniform recipe that can be applied anywhere.
    Clean code - is a code that is EASY to read, but difficult to write.
    There are tons of books on this topic and if you expect to receive an exhaustive unambiguous answer in this comment then I'll say:
    Sorry silver bullets are out of stock))

    If you want to see how to solve this kata in an imperative way without exiting in the middle of the loop take a look at my fork.
    That's doable with a help of break statement or labels. Caution, both of them can make the code cluttered, and labels are actually discouraged to use for that reason.

    By the way, your dubious attitude to streams is still unclear to me.
    Streams are effective, lazily evaluated, very nice in terms of readability, and capable to solve most of the problems which traditionally were implemented using loops.
    If you are striving to write clean then code functional style is more preferable over imperative. And that is the strongest suggestion in my answer.

    Now you are free to ignore this information or explore it father on your own. I hardly can add anything.
    Good luck.

  • Default User Avatar

    Single exit strategy is a controversial discussed dogma. For instance the Object.equals() method uses multiple return statements. Just have a look at the source code. Perhaps you shall advise Oracle that you think they're using bad pracice and improve the Java code base with a better solution. Your approach may be good for these concrete kata, but it is indeed not a general valid way, to solve all problems of that type, as you can see.

    Hence, my question was not about linking connections to anything, but wanting to know, how you would solve problems of that kind in general, if something like IntStream was not accessible. Since clairvoyance does not exist, nobody can elaborate how your solution would look like. This is just a red herring argument. I would be grateful, if you could take two minutes to show a good way that works even for cases when Streams don't work, with a single exit point. And of course, without a break in the loop, because it violates your choosen strategy.

  • Default User Avatar

    If it was a replay to my comment can elaborate on your thought. I'm not sure that I've understood correctly what you are trying to convey.
    What is the connection between import statements and best coding practices?

  • Default User Avatar

    How would you solve it without any imports like IntStream?

  • Loading more items...