8

Czy jakaś sprężarka zajmuje się usuwaniem obudów przełączników, które nie są wywoływane w dowolnym miejscu aplikacji?Usuwanie martwych kodów z obudów przełączników w JavaScript

function execute_case(id) { 
    switch(id) { 
    case 0: 
     console.log("0"); 
     break; 
    case 1: 
     console.log("1"); 
     break; 
    case 2: 
     console.log("2"); 
     break; 
    case 3: 
     console.log("3"); 
     break; 
    default: 
     console.log("default"); 
     break; 
    } 
} 

execute_case(1); 

Jeśli powyższe jest wszystkim, co mam, to teoretycznie przypadki 0,2,3 są martwe i nigdy nie zostaną wykonane. Czy jakaś kompresor ma inteligencję usuwania tego kodu podczas minimalizowania kodu?

Zajmuję się fragmentem kodu, który zawiera ponad 200 000 przypadków w komunikacie przełączającym, a stąd pytanie.

Dzięki, -Vikrant

+0

za to, że musicie zabrudzić sobie ręce materiałami do zbierania śmieci.i powiedzielibyście ... po prostu cieszcie się kodowaniem –

+5

Waham się zapytać, ale, 200K przypadek sprawy? WTF? –

+0

Kompilator nie może wiedzieć, że linia na dole jest jedynym miejscem, w którym funkcja zostanie kiedykolwiek wywołana. Możesz załadować później inny plik JS i może on wywołać funkcję z innym parametrem. – Barmar

Odpowiedz

3

Nie sir

Jak id jest zmienną, nie sprężarka "wie", że to nie może się zdarzyć. Kompresory nie analizują wartości zmiennych w instrukcjach przełączników i wiedzą, jak je usunąć.

Jeśli "wiesz", takie przypadki się nie zdarzą, po prostu usuń je samodzielnie.

+0

Rzeczywiście, zbyt wiele "co-jeśli", aby zagwarantować sprawę, nie zostanie trafione (co, jeśli przekazuje zmienną, co jeśli ta zmienna pochodzi z połączenia AJAX, co jeśli w grę wchodzi matematyka, co jeśli ...) –

+0

Polecenie, Brad. Mam nadzieję, że OP będzie słuchał. –

+1

Myślę, że spodziewa się, że kompilator zauważy, że funkcja jest wywoływana tylko z jednego miejsca, a to miejsce ma stały parametr, więc może wykonać stałe propagowanie do definicji funkcji. – Barmar

3

Nic nie będzie definitywnie podawać listę martwych przypadków. Jeśli jest napisane, że nie może istnieć żadna inna możliwość (rozgałęzienie skończonego kodu) lub kłamie. Więc jeśli nie znasz wszystkich możliwych wartości, które można przekazać execute_case, będziesz w ciemności. (I zakładam, że nie dałeś tego pytania).

Co można zrobić z zrobić mały rejestrator w tym kodzie, który wyprowadza/zapisuje wartości przekazywane do tego przełącznika. Następnie, przez [sporą ilość] czasu i/lub kilka tysięcy egzekucji, śledzić, które z nich są trafione, a które nie. Nie koniecznie usunęłbym te, które nie zostały trafione, ale może spróbuję je wycofać i poczekać na dłuższy czas/kolejne egzekucje, aż dojdziesz do wniosku, że nie jest już konieczne.

+0

cóż, w tym przypadku mam sposób na znalezienie wszystkich możliwych połączeń. Brak wywołań dynamicznych tutaj. Wszystkie są bezpośrednimi inwokacjami, których identyfikatorem przełącznika jest wyraźnie liczba. Kosztowało mnie to grep | uniq, aby uzyskać wszystkie ważne przypadki. Ale zestaw jest nadal bardzo duży (200K), aby ręcznie usunąć. istnieje również niebezpieczeństwo, że jeśli coś, co jest nieużywane dzisiaj, zostanie użyte jutro z powodu czegoś nowego, co dodamy, będziemy musieli to zrobić ponownie. Minifier zadba o to wszystko. może być minifier ze specjalnym przypadkiem (--strict_case_minification dla takich przypadków) – v2b

Powiązane problemy