Perché le schede sono maligne in ES6? [chiuso]

1

Come ho recentemente iniziato a utilizzare ES6 in produzione, stavo esaminando una guida allo stile ES6 (con più di 350 stelle su GitHub). Questa guida menziona almeno tre volte che "Le schede sono malvagie. Non usarle!"

Inoltre, un'altra guida allo stile JavaScript di AirBnB molto popolare raccomanda anche l'uso di 2 spazi per il rientro di utilizzare schede rigide.

Anche se ho usato schede per tutti i miei sviluppi frontend (ES5 ovviamente) e non ho avuto problemi fino ad ora. Voglio solo sapere perché le schede sono considerate malvagie in ES6? Ho pensato che fosse una questione completamente personale e non dovrebbe avere importanza. Ma ci sono degli scenari speciali in cui le schede possono davvero diventare cattive per lo sviluppo di ES6?

    
posta mg007 09.05.2017 - 07:46
fonte

1 risposta

6

Perché alcune persone sono sfortunatamente - stupide, e ancora non hanno notato che è il 2017 non il 1987 ... e faranno tutto per aggiungersi un po 'di lavoro perché il loro IDE / Text Editor è così vecchio o così zoppo, non è in grado di supportare correttamente il tab char stupido e configurabile.

E la seconda parte del problema è che l'architettura node.js è un DISASTER. Fino. Quasi nulla funziona come dovrebbe. A partire dalla mancanza di pianificazione di lavoro, e scrivendo il codice di pianificazione "a mano", a foreach loop non funzionanti in modo errato e nessun supporto di errore utilizzabile, terminando con il codice di callback annidato che è WORSE e più difficile da mantenere rispetto ai goto-spaghetti scritti nei primi giorni dell ' 90 Microsoft Basic.

Non mi sorprende che un gruppo di sviluppatori provenienti da un ambiente di persone che non riescono a ottenere un design stupido "per" loop - stia avendo un problema con un concetto così "complicato" come personaggio tab ... e aggiungere per la stupidità, tutto quello che possono dire è "le schede sono cattive". Beh, questa è una grande discussione;)

  • Le schede semplificano la lettura del codice per persone diverse su dispositivi diversi (in particolare le diverse proporzioni dello schermo)
  • Richiedi meno battitura
  • Non è necessario contare i caratteri, quindi è molto più semplice non commettere errori di formattazione
  • Non è necessario discutere come un idiota, sull'utilizzo di 2, 4 o 5 spazi ... lo hai impostato nell'editor
  • Sono progettati per fare rientrare non separare le parole, come lo spazio

"Le schede sono malvagie" equivale a sostenere che le interruzioni di pagina non devono essere utilizzate in DTP ... quindi eseguiamo l'allineamento utilizzando newline.

No, la frase corretta non è "le schede sono cattive", ma "siamo troppo stupidi per semplificare il nostro lavoro, quindi lavoreremo come negli anni '90". Non è un codice C Kernel in cui l'uso degli spazi è giustificato almeno storicamente, si suppone che il nodo sia un modo "moderno" di programmazione delle interfacce moderne.

JS è ottimo per lo sviluppo della UI, e SUCKS totalmente per il lato server. È interessante notare come persino la "guida allo stile" dica quanto sia stato progettato per il codice serveride, e quanto sia pessima questa "guida alla codifica", perché ANCORA ... qualche genio pensava che "taglia unica", per diffondere questo mito mitico di "codice che potrebbe essere utilizzato sia sul client che sul server" ... Quindi fai un favore a te stesso, se stai scrivendo serveride - stai lontano dal nodo. Usa golang, scala, c #, php, c ++, D ... qualsiasi cosa!

E non permettere troppe cose relative a JS di inquinare troppo il tuo ambiente di programmazione. Questi "requisiti" di codifica ... succede quando vuoi creare qualcosa che "si adatti a tutti" .... come, ad es. utilizzando setTimeout va perfettamente bene sullo sviluppo dell'interfaccia utente clientide, ma di solito non è una buona idea sul lato server.

Although I have been using tabs for all my frontend development

Come ogni essere umano sano di mente farebbe ora, se può ...

    
risposta data 09.05.2017 - 09:34
fonte

Leggi altre domande sui tag