Nazwa dla lekkich i ciężkich operacji

Odpowiedz Nowy wątek
2019-06-23 11:49
0

Otóż piszę funkcję która musi obsłużyć 10 przypadków

boolean check(Object o)

Dla 8 na 10 przypadków, operacja sprawdzająca jest bardzo szybka (kilkaset operacji na ms). Dla pozostałych 2óch na 10 przypadków szybka operacja sprawdzająca jest czasem nie wystarczająca, więc trzeba zrobić wolną operacją sprawdzającą. Kod powinien wyglądać tak:

boolean check(Object o) {
  if (szybka(o)) {
    return true;
  }
  return wolna(o);
}
  • Operacja szybka() potrafi tylko powiedzieć czy coś spełnia warunek:
    • true znaczy "na pewno spełnia"
    • false znaczy "nie wiadomo czy spełnia"
  • Operacja wolna() sprawdza już to na 100%:
    • true znaczy "na pewno spełnia"
    • false znaczy "na 100% nie spełnia"

No własnie, i nie wiem jak nazwać te metody, tak żeby było z samych nazw wiadomo:

  • Że szybka() jest optymalna, ale potrafi tylko powiedzieć "na pewno tak, ale nie wiadomo czy nie".
  • Że wolna() jest zasobożerna, ale potrafi na 100% ocenić poprawność.

Jakieś pomysły na nazwy?


edytowany 4x, ostatnio: TomRiddle, 2019-06-23 11:52
szybkaNiedokladnaOptymalna(); wolnaDokladnaNieoptymalna() xD - au7h 2019-06-23 11:55

Pozostało 580 znaków

2019-06-24 16:43
0

niech shallowCheck zwraca strukture shallowResult w ktorej bedziesz miec

ShallowResult {
  bool FalsePositive;
  bool FalseNegative;
}

I wtedy zmieniasz odpowiednio warunek i wynik operacji shallowCheck mowi Ci o tym ze moze to byc FalsePositive czy FalseNegative

PS nie wiem dokladnie o co chodzi, nie czytalem calego tematu, jedynie odnosze sie stwierdzenia o ktorym napisales o moim pomysle ;)

edytowany 1x, ostatnio: fasadin, 2019-06-24 16:44

Pozostało 580 znaków

2019-06-24 16:45
0
fasadin napisał(a):

niech shallowCheck zwraca strukture shallowResult w ktorej bedziesz miec

ShallowResult {
  bool FalsePositive;
  bool FalseNegative;
}

I wtedy zmieniasz odpowiednio warunek i wynik operacji shallowCheck mowi Ci o tym ze moze to byc FalsePositive czy FalseNegative

Nie chcę nic refactorować :| Warunek fast(a) && slow(a) jest ok! Chcę tylko lepszą nazwę.


To w końcu koniunkcja czy alternatywa? fastdaje false negative czy false positive? - Afish 2019-06-24 16:54
Afish: Racja, || miał być. - TomRiddle 2019-06-24 18:30

Pozostało 580 znaków

2019-06-24 16:48
0

Chcę tylko lepszą nazwę

no jak widzisz, nie mozesz ogarnac lepszej nazwy bo:

1) Chcesz opisac to co funkcja robi
2) Chcesz opisac to co funkcja zwraca

i to w samej nazwie funkcji

Przeciez to nie moze zadzialac tak by bylo czytelne i zrozumiale

ShallowCopyThatIsFastAndReturnsFalsePositiveOrNegativeSoYouCannotBeSure(a)
DeepCopyThatIsSlowAndReturnsBooleanBecauseResultIsGuaranteed(a)

to jest mniej wiecej co chcesz osiagnac poprzez nazwy (powiedzmy... zamiast shallowcopy czy deepCopy mozesz uzyc co tma chcesz)

edytowany 1x, ostatnio: fasadin, 2019-06-24 16:49

Pozostało 580 znaków

2019-06-24 16:55
0
fasadin napisał(a):

Chcę tylko lepszą nazwę

no jak widzisz, nie mozesz ogarnac lepszej nazwy bo:

1) Chcesz opisac to co funkcja robi
2) Chcesz opisac to co funkcja zwraca

i to w samej nazwie funkcji

Przeciez to nie moze zadzialac tak by bylo czytelne i zrozumiale

ShallowCopyThatIsFastAndReturnsFalsePositiveOrNegativeSoYouCannotBeSure(a)
DeepCopyThatIsSlowAndReturnsBooleanBecauseResultIsGuaranteed(a)

to jest mniej wiecej co chcesz osiagnac poprzez nazwy (powiedzmy... zamiast shallowcopy czy deepCopy mozesz uzyc co tma chcesz)

W sumie to nie, chcę zawrzeć w nazwie cechy algorytmu:

  • optymalny/wymagający
  • optymistyczny/pewny

Jest dużo takich metod które mają takie nazwy.


edytowany 1x, ostatnio: TomRiddle, 2019-06-24 16:55

Pozostało 580 znaków

2019-06-24 17:24
0
Afish napisał(a):

Mój tok myślenia można byłoby uprościć do:

  • Jeżeli nie piszesz cache'a per se, to napisz w dokumentacji przesłanki do użycia tej szybkiej ścieżki. Nawet proste stwierdzenie w stylu fast check to avoid I/O operations as this seems to speed up things też jest wartościowe, inny programista zrozumie, że niespecjalnie cokolwiek mierzyłeś i kierowałeś się intuicją, więc jak trzeba będzie to zmieniać, to nie będzie godziny myślenia „a może to zepsuje rzeczy gdzieś indziej / a może muszę robić benchmarki, czy to się wyrobi na produkcji”.

Całe te Twoje dwa ogromne posty nie specjalnie niosą jakąś wartość dla mnie, ponieważ:

  • po pierwsze, zadając pytanie nie szukałem pomocy w implementacji/optymalizacji, dlatego że...
  • po drugie, to czy funkcja się wykona 1ms czy 100ms z biznesowego punktu widzenia jest to żadna różnica
  • po trzecie, mam inne priorytety co do pracy nad aplikacją, niż performance'owe optymalizacje
  • po czwarte, całkowicie odbiegłeś od tematu (czyli dobrej nazwy) w stronę hiper-optymalizacji
  • po piąte, nie specjalnie chce mi się pokazywać dlatego akurat taką strategię wybrałem, dlatego że...
  • po szóste, gdybyś zobaczył ten kod, to sam sobie odpowiedziałbyś na 80% pytań i sądzę że doszlibyśmy do podobnego wniosku - że lepiej jest zrobić szybkiego check'a z mapy która już istnieje (nawet jeśli jej implementacja jest nieoptymalna), niż od razu walić do IO/Socket'ów, bo implementacja raczej nie będzie tak fatalna żeby była wolniejsza niż io/socket (jasne, możesz się nie zgadzać, ale nie tego dotyczyło pytanie).

Nawet proste stwierdzenie w stylu fast check to avoid I/O operations as this seems to speed up things też jest wartościowe, inny programista zrozumie, że niespecjalnie cokolwiek mierzyłeś i kierowałeś się intuicją

Wolałbym to zawrzeć w nazwie, niż w dokumentacji. W aplikacji są dziesiątki tysięcy funkcji, jasne że większość z nich nie będzie benchmarkowana osobno/razem, etc.

Poza tym, zauważ że to co napisałbyś w dokumentacji, dokładnie zawiera się w nazwach które próbuję znaleźć:

   fast check to avoid I/O operations as this seems to speed up things
// ↑ pierwsza nazwa
              // ↑ else
                   // ↑ druga nazwa, odnośnie "ciężkości" 
                                                  // ↑ pierwsza nazwa z "fast"

np:

if (fastCheckAvoidingIO(a)) {
  return true;
} else {
  return ioSocketTest(a);
}

i tada, dokumentacja nie jest potrzebna. Myślę że każdy kto uważnie przeczytał Clean Code'a doszedłby do podobnych wniosków.

Możesz też nazwać funkcję checkYadaYadaFastWithoutIOWithFalseNegativesjeżeli tak bardzo chcesz.

Też nie bardzo, bo nie chciałbym funkcji z 9 słowami w nazwie.

Może podkreślę - nie chcę w tym wątku się wypowiadać o optymalizacji, jeśli chcesz kontrybutować - proszę dopisz PR'a na githubie - ten wątek jest stworzony tylko z myślą o nazwach dla dwóch metod.


edytowany 4x, ostatnio: TomRiddle, 2019-06-24 17:31

Pozostało 580 znaków

2019-06-24 17:40
2

Czyli chcesz mieć w nazwie informację, że jest szybko, że omija IO, że może dać false negative, ale nie chcesz długiej nazwy, nie chcesz zmiany typów, no i zakładasz, że czytelnik kodu nie będzie zadawał pytań, które zadawałem ja (bo będzie wiadomo od kopa). Zgadza się? Powiedziałeś też

Jest dużo takich metod które mają takie nazwy.

To może podaj jakieś przykłady, bo trochę to wygląda tak, jakbyś szukał jakiegoś ładnego angielskiego słowa, które zawrze wszystkie informacje, a nie będzie miało dużo znaków.

Pozostało 580 znaków

2019-06-24 18:15
0
Afish napisał(a):

Czyli chcesz mieć w nazwie informację, że jest szybko, że omija IO, że może dać false negative, ale nie chcesz długiej nazwy, nie chcesz zmiany typów,

Nie muszę mieć informacji o IO, wystarczy tylko że fast i że false negative. Noi to jest oczywiste że nie chcę zbyt długiej nazwy. Zmiana typu jest niepotrzebna.

no i zakładasz, że czytelnik kodu nie będzie zadawał pytań, które zadawałem ja

Nawet gdyby zadał, co mnie to? W aplikacji jest 10000 funkcji które mają nazwy na 2-4 słowa i jakoś nikt pytań nie zadaje.

To może podaj jakieś przykłady, bo trochę to wygląda tak, jakbyś szukał jakiegoś ładnego angielskiego słowa, które zawrze wszystkie informacje, a nie będzie miało dużo znaków.

Jedno angielskie słówko było by miodzio (jak np memoize() zamiast np getFromStoreOrEvaluate() czy coś).

I nie koniecznie musi mieć mało znaków. Mówiłem że chcę mało słów - nie krótkie słowa.


edytowany 1x, ostatnio: TomRiddle, 2019-06-24 18:17

Pozostało 580 znaków

2019-08-01 22:20
0

1) existsNonExactFast
2) existsExactSlow

Nieprecyzyjna często jest szybka i na odwrót, to samo z dokładnością i powolnością. Osobiście wybrałbym shallow i deep.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0