Chciałbym wiedzieć, czy dobrą praktyką jest generalizacja zmiennych (użyj jednej zmiennej do przechowywania wszystkich wartości).
Rozważ prosty przykład
Strings querycre,queryins,queryup,querydel;
querycre = 'Create table XYZ ...';
execute querycre ;
queryins = 'Insert into XYZ ...';
execute queryins ;
queryup = 'Update XYZ set ...';
execute queryup;
querydel = 'Delete from XYZ ...';
execute querydel ;
i
Strings query;
query= 'Create table XYZ ... ';
execute query ;
query= 'Insert into XYZ ...';
execute query ;
query= 'Update XYZ set ...';
execute query ;
query= 'Delete from XYZ ...';
execute query ;
W pierwszym przypadku używam 4 łańcuchów, z których każdy przechowuje dane, aby wykonać czynności wymienione w ich przyrostkach.
W drugim przypadku tylko 1 zmienna do przechowywania wszystkich rodzajów danych.
Posiadanie różnych zmiennych ułatwia komuś innemu czytanie i zrozumienie go lepiej. Ale posiadanie zbyt wielu z nich utrudnia zarządzanie.
Czy zbyt wiele zmiennych utrudnia moją wydajność?
PS: proszę nie odpowiadaj na kod w przykładzie, aby po prostu przekazać to, co naprawdę mam na myśli.
programming-practices
variables
Shirish11
źródło
źródło
Odpowiedzi:
Zadanie sobie tego pytania jest dość silnym zapachem, że nie podążasz za OSUSZANIEM (nie powtarzaj się). Załóżmy, że masz to w hipotetycznym języku nawiasów klamrowych:
Przeanalizuj to w:
Zauważ, że odchodzi potrzeba podjęcia decyzji, czy użyć różnych zmiennych, i jak możesz teraz zmienić logikę uruchamiania zapytania i drukowania wyniku w jednym miejscu, zamiast trzykrotnego zastosowania tej samej modyfikacji. (Na przykład możesz zdecydować, że chcesz przepompować wynik zapytania przez system szablonów zamiast drukować go od razu).
źródło
runAndPrint
wypycha jedną ramkę stosu, gdy ją wywołujesz, a następnie odsuwa ją po wyjściu z funkcji. Jeśli wywołasz go trzy razy, wykona trzy pary push / pop, ale stos nigdy nie rośnie o więcej niż jedną klatkę na raz. Powinieneś naprawdę martwić się o głębokość stosu wywołań dzięki funkcjom rekurencyjnym.Zwykle jest to zła praktyka.
Ponowne użycie zmiennej może w ten sposób sprawić, że kod będzie mylący z odczytaniem zrozumienia.
Osoby czytające kod nie będą oczekiwać ponownego użycia zmiennej w taki sposób i nie będą wiedziały, dlaczego wartość ustawiona na początku ma inną wartość na końcu funkcji.
Opublikowane przez ciebie przykłady są bardzo proste i tak naprawdę nie cierpią z powodu tego problemu, ale nie są reprezentatywne dla jakiegoś kodu, który ponownie wykorzystuje zmienne (gdzie jest ustawiony na początku, jest ponownie używany gdzieś pośrodku - poza zasięgiem wzroku).
Podane przykłady nadają się do enkapsulacji w funkcjach, w których można przekazać zapytanie i wykonać je.
źródło
Kod udokumentowany jest łatwiejszy do odczytania i utrzymania
Postępuj zgodnie z zasadą najmniejszego oczyszczenia i zasadą kodowania jako dokumentacji : użyj jednej zmiennej dla jednego celu, aby zarówno jej użycie było łatwe do zrozumienia, jak i kod łatwy do odczytania bez wyjaśnień.
Prawidłowo skonstruowany kod jest łatwiejszy (a więc tańszy) do (ponownego) użytkowania
Tutaj również wydaje się, że
query
zawsze jest on używany do przygotowania instrukcji przed jej wykonaniem. Prawdopodobnie jest to znak, że chcesz zmienić część tego kodu na jedną (lub więcej) metod pomocniczych w celu przygotowania i wykonania zapytania (aby zachować zgodność z zasadą DRY ).W ten sposób skutecznie:
Przykłady:
Rozważ to, wzięte z twojego przykładu, gdzie wersja refaktoryzowana jest oczywiście lepsza. Oczywiście Twój fragment kodu był tylko przykładem na potrzeby tego pytania, ale koncepcja nadal jest prawdziwa i skaluje się.
Twój przykład 1:
Twój przykład 2:
Przykład 3 (Refaktoryzowany pseudo-kod):
Korzyść wynika z regularnego ponownego użycia.
Anegdota osobista
Zaczynałem jako programista C pracujący z ograniczoną powierzchnią ekranu, więc ponowne użycie zmiennych miało sens zarówno dla skompilowanego kodu (wtedy), jak i dla umożliwienia odczytania większej ilości kodu na raz.
Jednak później przeszedłem na języki wyższego poziomu i nauczyłem się programowania funkcjonalnego, przyzwyczaiłem się używać niezmiennych zmiennych i niezmiennych referencji, o ile to możliwe, aby ograniczyć skutki uboczne.
Co będę z tego mieć?
Jeśli przyzwyczaisz się, że wszystkie dane wejściowe funkcji są niezmienne i zwrócisz nowy wynik (tak jak zrobiłaby to prawdziwa funkcja matematyczna), nabędziesz zwyczaju nie powielania sklepów.
W rezultacie prowadzi to do:
Nie twierdzę, że nie ma tu żadnej korzyści ze stanu zmienności, po prostu wskazuję, w jaki sposób nawyk może rozwinąć się na tobie i jak wpływa na czytelność kodu.
źródło
W zakresie projektowania kodu
Zasadniczo można ponownie wykorzystywać zmienne do przechowywania różnych wartości - w końcu dlatego nazywane są zmiennymi, ponieważ wartość w nich przechowywana jest różna - o ile wartość jest nie tylko tego samego typu, ale także oznacza to samo . Na przykład, oczywiście, można ponownie użyć
currentQuery
zmiennej tutaj:Naturalnie istnieje pętla więc mieć do ponownego użycia zmiennej, ale nawet jeśli nie było pętli byłoby w porządku. Jeśli wartość nie oznacza tego samego, użyj oddzielnej zmiennej.
W szczególności opisywany kod nie wygląda zbyt dobrze - powtarza się . O wiele lepiej jest używać wywołań metod pętli lub pomocników (lub obu). Osobiście bardzo rzadko widuję kod produkcyjny, który wygląda na twoją pierwszą lub drugą wersję, ale w takich przypadkach myślę, że druga wersja (zmienne ponowne użycie) była bardziej powszechna.
Pod względem wydajności
Zależy to od używanego języka, kompilatora i systemu uruchomieniowego, ale ogólnie nie powinno być żadnej różnicy - w szczególności kompilatory dla rejestrów opartych na stosie (jak popularny x86 / x86-64) i tak po prostu użyj dowolnej wolnej pamięci stosu lub rejestru, które mogą, jako celu przypisania, całkowicie ignorując, czy chcesz tę samą zmienną, czy nie.
Na przykład
gcc -O2
generuje dokładnie ten sam plik binarny, a jedyną znaną mi różnicą wydajności jest wielkość tabeli symboli podczas kompilacji - całkowicie nieistotna, chyba że cofniesz się w czasie do lat 60.Kompilator Java wygeneruje kod bajtowy, który potrzebuje więcej miejsca dla 1. wersji, ale jitter JVM i tak go usunie, więc podejrzewam, że praktycznie nie będzie zauważalnego wpływu na wydajność, nawet jeśli potrzebujesz wysoce zoptymalizowanego kodu.
źródło
Myślę, że ponowne użycie zmiennej jest w porządku przez większość czasu.
Dla mnie przez większość czasu po prostu ponownie używam zmiennej zapytania. Prawie zawsze wykonuję zapytanie zaraz po. Kiedy nie wykonuję zapytania od razu, zwykle używam innej nazwy zmiennej.
źródło
Może zwiększyć użycie stosu, jeśli twój kompilator jest szczególnie głupi. Osobiście nie sądzę, aby oddzielna zmienna dla każdego zapytania w ogóle zwiększała czytelność, nadal trzeba spojrzeć na ciąg zapytania, aby zobaczyć, co robi.
źródło
W tym przykładzie wybrałbym drugi przykład. To, co robisz, jest jasne zarówno dla czytelnika, jak i optymalizatorów. Pierwszy przykład jest nieco bardziej odpowiedni i przy nieco bardziej skomplikowanym kodzie użyłbym go, ale zrób to tak:
(W tym momencie mogę rozważyć rozwiązanie tdammers .)
Problem z pierwszym przykładem dotyczy
querycre
całego bloku, który może być obszerny. Może to wprowadzić w błąd osobę czytającą kod. Może także mylić optymalizatory, które mogą pozostawić niepotrzebne zapisy w pamięci, więc będąquerycre
dostępne później, jeśli zajdzie taka potrzeba (co nie jest). Ze wszystkimi nawiasami klamrowymiquery
jest przechowywany tylko w rejestrze, jeśli to.W przypadku takich zwrotów, jak „Utwórz tabelę” i „uruchom”, nie wygląda mi to na dodatkowe zapisanie w pamięci, więc zaryzykuję kod za pomyłkę w czytaniu. Ale warto o tym pamiętać, jeśli piszesz kod, w którym prędkość ma znaczenie.
źródło