prymitywy Przypisywanie JavaScript, żeby ich odpowiednik zmiennej o nazwie jak „stałe”

Question

Szukałem w kodzie źródłowym do qTip 2 i zobaczył, co następuje:

// Munge the primitives - Paul Irish tip 
var TRUE = true, 
    FALSE = false, 
    NULL = null; 

nie mogę wymyślić powód, jeśli kiedyś to zrobić i mają silne poczucie, że po prostu zachęcałoby to do złych nawyków w kodowaniu. Powiedzmy, że deweloper tworzy literówkę w stanie Yoda, takim jak if (TRUE = someCondition()), a następnie TRUE może bardzo dobrze skończyć w rzeczywistości oznaczając false, lub możesz zakończyć przypisywanie someObject do NULL.

Chyba jestem po prostu zastanawiasz się, czy jest jakiś zbawczą jakość tej praktyce, że mi brakuje, lub jeśli jest to tylko zwykły stary Bad Idea ™

Answer 1

Celem tego jest po prostu poprawa kompresji, sam Paul Irish nazywa to "anty-wzorem".

Opisuje go jako "Dobre dla kompresji i łańcucha zakres przechodzenia" na poniższej prezentacji:

• jQuery Anti-Patterns for Performance & Compression (przesuń 46)

na łańcuszku zakres przechodzenia, nie będziemy patrz jakakolwiek poprawa w literałach, ponieważ łańcuch zasięgu nie jest kontrolowany, są tylko literałami.

W przypadku innych identyfikatorów, takich jak undefined lub windows, ruch łańcucha zakresu jest rzeczywiście kontrolowany.

Answer 2

Wierzę, że to jest zalecany do kompresji.

Te zmienne skrótów zostaną skompresowane po zmultipleksowaniu, co spowoduje powstanie mniejszych plików. Jednak twoje zauważone wady są z całą pewnością ważnymi punktami!

Answer 3

Można to zrobić ze względu na kompresję kodu. Na przykład kompresor YUI nie będzie dotykał true i false, ale może zastąpić wszystkie wystąpienia, na przykład TRUE z A, zapisując cztery znaki na wystąpienie. Na przykład, przed kompresją:

if (foo === null) { 
     bar = true; 
    } 

Po kompresji, zakładając sprężarkę zastępuje TRUE z a i NULL z c:

if(foo===c){bar=a;} 

Versus to po kompresji bez "munging prymitywów":

if(foo===null){bar=true;} 

Złe przyzwyczajenie-niebezpieczeństwa, które całkiem poprawnie cytujesz w swoich pytaniach może przeważyć małe oszczędności dodatkowej kompresji. To zależy od tego, jak rozpaczliwie chcesz uratować kilkadziesiąt, a może kilkaset bajtów.

Osobiście chciałbym (prawie) nigdy tego nie robić. Zbyt niebezpieczne.