È un problema avere stili diversi di codifica HTML all'interno del team?

Fa parte della competenza dell'autore HTML essere in grado di leggere il markup HTML scritto in diversi stili (ad esempio, annidamento, maiuscolo ~ minuscolo, virgolette attorno ai valori degli attributi).

In un grande progetto potrebbe essere utile decidere su tali argomenti. Ancora più importante, sono necessarie decisioni su problemi di livello superiore come l'uso di tag, la denominazione di attributi id e classe, l'uso di fogli di stile esterni e script rispetto a stili e script incorporati e conformità alle specifiche HTML (HTML 4.01 ~ XHTML 1.0 ~ HTML5 ~ qualcos'altro).

Hai ancora bisogno di mantenere HTML / CSS. Come dici tu:

we tend to put a good amount of time in understanding why the other one does that

Solo perché è un markup non significa che dovresti ignorare le buone pratiche di lavoro in un team.

Se ti standardizzi su come fare le cose, tali oneri di manutenzione saranno notevolmente ridotti.

Se lavorerai regolarmente al codice degli altri, dovrai essere in grado di leggerlo. Altre persone potrebbero persino aver bisogno di leggerlo.

Puoi imparare a leggere diversi stili di codice, ma il problema emerge quando devi cambiare mentalità quando guardi diverse sezioni di codice. C'è un costo molto evidente implicato in questa opzione . A volte è inevitabile, come passare dalla lettura di un lang funzionale alla lettura del codice orientato agli oggetti, ma quando devi cambiare il modo in cui leggi solo per leggere le pagine casuali del codice del tuo sito, si aggiunge rapidamente.

Se entrambi avete bisogno di lavorare regolarmente sul rispettivo codice, il costo è destinato a sommarsi e probabilmente vi entrerete in discussioni riguardo allo stile del codice: "Perché il% $ ^% sta facendo che ?"

Inoltre è importante che anche se tutte le tue pagine HTML sono separate e non è necessario che siano coerenti nel modo in cui gli ID di utilizzo, le classi ect, il tuo CSS e il tuo backend fanno hanno bisogno coerenza . Affinché il tuo CSS abbia un senso, devi capire come utilizzerai classi vs ID e il tuo nome per gli elementi. Le tue forme avranno bisogno di alcuni standard perché i nomi delle variabili che usi per i tuoi moduli tornano nel livello del server, e devono mappare bene agli input del database, laddove rilevanti.

Anch'io certamente non scarterei la nozione di codice leggibile dal momento che si tratta di un linguaggio di marcatura piuttosto che di un linguaggio di programmazione; semmai importa più nel markup perché il tuo codice non è compilato e il markup non semantico potrebbe effettivamente essere visualizzato in modo errato o avere problemi di accessibilità.

Esiste un solo punto in cui si incontrano il lato server e tutti i problemi sul lato client e questo è l'HTML. Dovrebbe essere la porzione più fedele e ritentiva di ogni app web, la più pura, più pulita, più consistente e con il carbone ridotto al diamante.

Immagina di afferrare e ristrutturare una stringa da innerHTML. Quanto è più facile quando sai che saranno sempre le virgolette su ogni attributo e ogni elemento in stile singolare avrà quella chiusura '/'? Quando è a tarda notte e stai provando a leggere un po 'di codice, quanto è utile essere in grado di separare facilmente ID e classi che hanno una convenzione di trattino o trattino da nomi di proprietà e var di tipo tradizionale?

E davvero, quanto è più semplice leggere HTML quando tutto segue le stesse convenzioni.

Non è difficile mantenere l'HTML pulito e coerente e ci sono troppe vincite da non fare. Gli sviluppatori lato server che trattano l'HTML come un mezzo monouso per un fine non stanno capendo l'app Web da una prospettiva globale IMO. E il loro codice di solito è anche sciatto.

questo è un problema all'interno del nostro team, dove ci sono due diversi sviluppatori HTML che hanno stili di codifica diversi, ma non impongono loro alcunché specifico, in modo che possano lavorare in modo efficiente e felice. E non abbiamo mai riscontrato un problema in cui i due non sono completamente in grado di comprendere l'un l'altro html.

Lo stesso vale per qualsiasi stile di programmazione.

Fondamentalmente è necessario avere considerazioni speciali su "documentare il codice". E tutto andrà bene.

Non mi perderei troppo, specialmente con HTML.

Ho lavorato in molti posti con gli standard di codifica e non sono mai stati rispettati rigidamente.

Questo non vuol dire che non sono d'accordo con il fatto di averne una tale, solo che col tempo, a meno che non siano strettamente applicate, le persone si allontanano presto da loro.