Sens deklaracji redundantnych zmiennych

Popatrzmy na poniższe przykłady:

const parsedData = parseInputData(data);
useData(parsedData);

useData( parseInputData(data));

Oba dają ten sam efekt, różnica jest tylko w deklaracji typu const. Czy jest sens deklarować consta w takich przypadkach? Jedyny przypadek to sytuacja, gdy potrzebuje parsedData więcej niż raz. Czyli zamiast wywoływać kilka razy parseInputData() robię to raz.
Więc tak naprawdę rozbiega tu się tylko o czytelność. Tak/nie?

To zależy.

Uważam, że nie ma sztywnych reguł i trzeba z wyczuciem.

W powyższym przypadku bym nie wydzielał zmiennej, bo useData(parseInputData(data)); jest wystarczająco czytelne.

Ale jakbyś miał zamiast samego coś dłuższego i mniej czytelnego. Np.

useData(parseInputData(data.filter(item => item.active && item.date < params.date)));

to już można by było wydzielić zmienną np.

const filteredData = data.filter(item => item.active && item.date < params.date);
useData(parseInputData(filteredData));

Wtedy taka dodatkowa zmienna pokazałaby mocniej intencje i nakierowywałaby na to, co się znajduje w tych danych.

rafal95p napisał(a):

Popatrzmy na poniższe przykłady:

Kopiuj

const parsedData = parseInputData(data);
useData(parsedData);

Kopiuj

useData( parseInputData(data));

Nie ma żadnej różnicy w działniu.

Jedyne co daje taka zmienna to szansa nazwania zmiennej. Tutaj mamy parsedData i praseInputData(), czyli nie ma po co.

Nazwanie zmiennej miałoby sens np:

const height = Math.sin(angle);
useData(height);

Są dwie zalety:

1. Czytelność - można kod przeczytać od końca, wiemy że do useData przekazujemy parsedData, jeśli wiemy co ma zawierać parsedData to na tym etapie jeśli nie interesują nas detale możemy przerwać czytanie, jeśli chcemy się dowiedzieć szczegółów, to możemy skoczyć do deklaracji zmiennej(/stałej). Nie ma też potrzeby pisania komentarza - nazwa zmiennej sama w sobie jest komentarzem. Takie same korzyści jak z rozbijania kodu na funkcje.
2. Łatwiejsze debugowanie - dużo łatwiej ustawić breakpoint na useData i obejrzeć co jest w parsedData. Jeśli mamy to w jednej linii i będziemy chcieli wejść do useData a nie parseInputData lub na odwrót to będzie to lekko utrudnione, szczerze to nawet nie wiem w moim IDE jaki jest skrót klawiszowy na ustawienie breakpointa w środku linii i w takich przypadkach muszę czasem korzystać z myszki. Najlepiej jest jak w jednej linijce znajduje się maksymalnie jedno wywołanie funkcji. Możemy też podmienić wartość zmiennej podczas debugowania w dowolnej chwili, z podmianą zwróconej z funkcji wartości już nie jest tak łatwo.

Nie ma praktycznie wad, kompilator i tak prawdopodobnie wytworzy identyczny kod.

Tak jak wspomniano, głównie do debugowania tak robię. Czasem tez rozwlekam jak ten kawałek kodu jest przetestowany, a mi brakuje trochę % żeby zaspokoić code coverage w sonarze

W zależności od jezyka tego typu wywołania nie muszą być tożsame. W C++ kod:

const int a = foo();
const int b = bar();
goo(a, b);

Nie jest równoważny

goo(foo(), bar());

W tym pierwszym jest gwarantowane, że foo zostanie wywołane przed bar, W drugim nie ma takiej gwarancji, ponieważ kolejność ewaluacji argumentów funkcji nie jest zdefiniowana. Jeżeli zatem foo i bar mają jakieś efekty uboczne, to takie inline'owanie może nie być właściwe i potencjalnie prowadzić do trudnego do znalezienia błędu (co jest zatem swoją drogą argumentem za tym, by robić czyste funkcje).

W C++ i Rust to może nie być równoważne również z jeszcze jednego powodu - czas życia obiektu tj. moment w którym są wywoływane destruktory może być inny w zależności od sposobu przekazania wartości do funkcji.

W przypadku gdy obiekt trzyma jakiś zasób może mieć to istotne znaczenie dla wydajności a nawet i poprawności (np. blokady).

Kod:

use_data(&parse(data));
other_stuff();

jest równoważny:

let tmp = parse(data);
use_data(&tmp);
drop(tmp);
other_stuff();

Tymczasem gdybyśmy to napisali tak:

let tmp = parse_data();
use_data(&tmp);
other_stuff();

to tmp zostanie zniszczone dopiero po other_stuff. Jeśli tmp trzyma locka lub ma inny side-effect to wywołanie other_stuff może działać inaczej.

Przy czym taka różnica występuje jedynie przy użyciu referencji. W przypadku przekazania normalnie bez & lub przez move w C++, obie wersje są równoważne bo destrukcja nastąpi wewnątrz use_data.

Ciekawe. Właśnie zdebugowałem jedną rzecz właśnie tym, że miałem consta.

rafal95p napisał(a):

Ciekawe. Właśnie zdebugowałem jedną rzecz właśnie tym, że miałem consta.

To samo można zrobić watchem w debuggerze.