Magic values - dlaczego nie

Dobry temat.
Gdzie 7 uzylbym jako literalu?
Raczej nigdzie.
Po to sie tworzy stale zeby moc nadac glebszy sens wartosciom, gdyz same w sobie nie przedstawiaja wartosci merytorycznej, podobnie jak 19171216 czy 'ACC'. Dopiero w kontekscie, nadanym najlatwiej przez stala, mozna mowic o jakims znaczeniu tej wartosci

OP: Jak nie akeptujesz tego ze wiekszosc programistow nie lubi magic numbers to mozesz strolowac system tworzac stale:

final String first = "first";
final int one = 1;
final boolean TRUE = true;

To sa przyklady z zycia wziete - zdarzaja sie programisci zarowno COBOLa jak i Javy ktorzy maja podobne do Ciebie podejscie

piotrpo napisał(a):

Clean code przestał już być argumentem w przypadku części języków. Takie objective c, gdzie musisz np. podać nazwę parametru. Przykład który podałem wyżej wyglądałby tak (na ile nie udało mi się zapomnieć):

Ale przecież w "Clean Code" nie chodzi o to, żeby stosować jakiś utarty schemat formatowania i nazewnictwa, tylko żeby starać się pisać kod tak żeby był opisowy. Są w książce przykłady, których nie można odnieść do Objective C, ale nie przykłady są esencją książki, tylko idea, żeby kod dało się czytać i go zrozumieć stosunkowo łatwo.

Magic values to wartości o nieznanym znaczeniu i pochodzeniu, a nie przeznaczeniu. Nazwane parametry rozwiązują problem przeznaczenia, co przekłada się na czytelność wywołania funkcji i to fajny mechanizm, ale nadal nie czyni wartości magicznej mniej magiczną. Ani Chunk(7), ani Chunk(chunkSize: 7) nie wyjaśniają, czemu akurat 7.

Użycie nazwanych parametrów ani trochę nie kłóci się z odmagicznieniem wartości przez wsadzenie jej do stałej o opisowej nazwie (albo sensownym komentarzem, chociaż ja raczej wybrałbym stałą bo z komentarzami to różnie bywa w czasie rozwoju kodu).

Charles_Ray napisał(a):

Poziom dyskusji raczej niski. Znowu ze skrajności w skrajność.

Wynoszenie magic numbers do stałych ma charakter głównie dokumentacyjny, poprawiający czytelność kodu. Mówisz „czym jest to 7” - czy to jakiś default, powszechnie znana wartość, wartość zapewniająca jakiś konkretny flow itd. Dodatkowy atut to możliwość reużycia takiej stałej w innym miejscu. Czy trzeba to stosować bezmyślnie zawsze i wszędzie?

To możliwe, dzięki za krytykę.

Myślę, że istotnie mam skłonność do wpadania ze skrajności w skrajność: od kontestowania wszystkich tzw. "dobrych praktyk" i wzorców na zasadzie buntu nastolatka grozi mi przejście do traktowania ich jako sztywnych reguł i oceniania kodu nie na podstawie tego, czy spełnia określone zadanie i czy został napisany w sensownym czasie, ale na tej podstawie, czy ściśle przestrzega jakiegoś zalecenia, które kiedyś tam zasłyszałem.

@stivens: odpisuję w poście, bo to jest dyskusja na temat.

To co mowisz z jednej strony wydaje mi sie miec sens a z drugiej strony const val PI = 3.14 przeciez nijak nie tlumaczy dlaczego to ma wartosc akurat 3.14 (czyli bodajze stosunek obwodu do srednicy) a nie inna.

Liczba Pi ma taką wartość, bo tak została wyznaczona, i wiedza o tym jest wiedzą co najmniej elementarną.

Tak samo jak bedzie const val IMGS_PER_PAGE = 7 to to nie wytlumaczy dlaczego akurat 7 a nie 8 — stivens dziś, 13:39

Dlatego to jest beznadziejna nazwa stałej, bo znowu mówi o przeznaczeniu, a nie znaczeniu. Ale już OptymalnaLiczbaStandardowychPaskówNaStronęA4 powie chyba wszystko.
No chyba, że faktycznie o liczbę dni w tygodniu chodzi, to można to inaczej nazwać. :)

somekind napisał(a):

Magic values to wartości o nieznanym znaczeniu i pochodzeniu, a nie przeznaczeniu. Nazwane parametry rozwiązują problem przeznaczenia, co przekłada się na czytelność wywołania funkcji i to fajny mechanizm, ale nadal nie czyni wartości magicznej mniej magiczną.

Liczba czasami musi być, a to że ją nazwiemy czy nawet wyciągniemy z kodu do pliku konfiguracyjnego nie uzasadnia dlaczego jest akurat tyle.
Jest tyle bo jest, bo musi być, albo ktoś zdecydował że tyle ma być. Można to ewentualnie opisać w komentarzu, albo dokumentacji…

Zdarzyło mi się kilka razy popełnić tego typu mnożenia:

const int bufferSize = 4 * 1024 * 1024;
const int timeout = 24 * 3600;

dzięki jawnemu mnożeniu wiadomo że chodzi o 4 megabajty i 24 godziny w sekundach, łatwo też na oko ocenić czy nie ma pomyłki, podczas gdy wymnożone stałe byłyby znacznie mniej czytelne:

const int bufferSize = 4194288; // 4 MB
const int timeout = 86400; // 24 h

— dobrze jest czy nie? ;)

Azarien napisał(a):

Liczba czasami musi być, a to że ją nazwiemy czy nawet wyciągniemy z kodu do pliku konfiguracyjnego nie uzasadnia dlaczego jest akurat tyle.
Jest tyle bo jest, bo musi być, albo ktoś zdecydował że tyle ma być. Można to ewentualnie opisać w komentarzu, albo dokumentacji…

Pisałem, że w ostateczności (czyli jeśli trudno jest nadać nazwę wyjaśniającą kontekst) można komentować - tylko potem o taki komentarz trzeba dbać.

— dobrze jest czy nie? ;)

A czemu miałoby nie być dobrze? Też często używam mnożenia do zdefiniowania stałych, tylko nie widzę związku z tym tematem.