[pottymouth]

Mirki możecie ocenić mi jakość kodu? Wiem, że pewne zadania mają wiele rozwiązań ale wole nie karmić złych nawyków. To jest dla mnie stresujące jak udaje mi się rozwiązać problem a okazuje się, że można to było zrobić inaczej ( ͡° ʖ̯ ͡°)

Given a string, return true if it ends in "ly".
http://codingbat.com/prob/p103895
Moja wersja:

public boolean endsLy(String str) {

 if (str.length() >= 2 &&str.substring(str.length()-2).equals("ly")) {
 return true;
 }

 return false;
}

inna wersja:

public boolean endsLy(String str) {
return(str.length()>=2 && str.substring(str.length()-2).equals(“ly”));
}

#java #pytaniedoeksperta #programowanie

[sokytsinolop]

@pottymouth: a nie można tak :D

return charAt(string.length())=='y'

[jurny]

http://beginnersbook.com/2013/12/java-string-endswith-method-example/

[sokytsinolop]

@jurny: no dobra, ale on chce napisać implementacje żeby się czegoś nauczyć

[jurny]

@sokytsinolop: w treści zadania nie ma nic o implementacji

a jak chce ocenić swoje rozwiązanie, to może zerknąć do javadocsów tej metody

[sokytsinolop]

@jurny: a no tak, to wystarczy skopiować ze stackoverflow i zadanie zrobione, po co się zastanawiać i wynieść coś z lekcji skoro można tak ( ͡° ͜ʖ ͡°)

[sokytsinolop]

@pottymouth: teraz zobaczyłem że ma się kończyć na 'ly'
więc może

return (charAt(string.length())=='y' && return charAt(string.length()-1)=='l')

[dzeksondzekson]

@pottymouth:

Ja mam po prostu tak jak w tej innej wersji

public boolean endsLy(String str) {

return str.length() >= 2 && str.substring(str.length() - 2).equals("ly");

}

nie ma co rozmyślać specjalnie nad takim zadaniem, generalnie chodzi o to żeby był nawyk porównywania stringów metodą .equals bo to porównuje wartość Stringa w przeciwieństwie do == które porównuje czy dany string jest w tym samym miejscu w pamięci co inny.

[GrinDeN]

`public boolean endsLy(String str) {

return(str.length()>=2 && str.substring(str.length()-2).equals(“ly”));

}

@pottymouth: zdecydowanie ten styl, z tym, że:
1. popraw formatowanie bo średnio czytelne (chyba, że wykop Ci popsuł)
2. nawias tuż po return (okalający) Ci nie jest potrzebny
3. nie sprawdzasz tu nullowego przypadku

[P.....3]

@sokytsinolop: Nie można użyć endsWith()? To dla nas nie problem!

new StringBuilder(string).reverse().toString().startsWith("yl")

[y.....n]

"ly$" hehe

[YuiMizuno]

@sokytsinolop: a co jak długość stringa wynosi 1 albo 0? :D

[S.....h]

@YuiMizuno: albo string jest nullem ᶘᵒᴥᵒᶅ

[sometwo]

@pottymouth twoje rozwiazanie jest dobre to raz. A dwa jak zaczniesz pisac wieksze rzeczy to Ci sie odechce myslec nad takimi rzeczami xD serio... Sam na poczatku dopieszczalem kod a dzis klepie jak leci bo czas ucieka

[another_throwaway23]

@pottymouth argument "str" metody oznacz jako final - informujesz użytkownika, że metoda nie dokonuje modyfikacji tego argumentu. brakuje sprawdzania czy str == null. możesz też dać adnotację @NonNull na argumencie - kolejna informacja dla użytkownika, że nie powinien dostarczyć nulla.

[sokytsinolop]

@YuiMizuno:
@Sarseth: nie wiem, to była moja pierwsza przygoda z Java

[pottymouth]

@sokytsinolop: @another_throwaway23: @sometwo: @Sarseth: @YuiMizuno: @GrinDeN: @dzeksondzekson: @jurny:
Dziękuje wszystkim za odpowiedzi ( ͡° ͜ʖ ͡°)

[Viters]

@Sarseth: Piszmy kod tak, aby nie przekazywać nulli. Wtedy nie będzie trzeba wszędzie ich sprawdzać.

[S.....h]

@Viters: My możemy tak pisać. Też jestem za tym, poniekąd.
Ale co jak ktoś korzysta z Twojego API? Dasz mu info żeby nulli nie wrzucał w dokumentacji? Ale jego zespół pisze inaczej, bo nie narzucisz im tego, już nie Twój zespół niestety. Czyli zwrócisz NPE jeśli jednak wrzucą nulla. Teraz gościu wywołuje Twoją metodę 500 razy i 500 razy musi robić if(CośUtil.isNotEmpty(value)) {callYourMethod(value);} Albo catcha (╥﹏╥) na

[Viters]

@Sarseth: Zgadzam się, API faktycznie możemy dodatkowo zabezpieczać. Jednak z drugiej strony, przyjęcie jakiejś zasady nieodpowiadającej innemu zespołowi nie oznacza, że jest on skazany na męczarnie podczas implementacji. Można zastosować adapter, co jest dosyć dobrą praktyką. Nawet, gdy api w większości nam odpowiada.