Il nostro team dovrebbe ordinare in modo coerente i metodi e le proprietà della classe Javascript? Se é cosi, come?

2

Mentre il nostro team sta crescendo ho notato che diversi sviluppatori mettono i loro metodi di classe in ordini diversi. Ad esempio:

var Foo = Backbone.Model.extend({
    someVar: {},

    initialize: function() {...},

    fetch: function() {...},
    handleFetchRepsonse: function() {...},

    getFoo: function() {...},

    render: function() {...},
    renderFoo: function() {...},
});

vs.

var Foo = Backbone.Model.extend({
    fetch: function() {...},
    getFoo: function() {...},
    handleFetchResponse: function() {...},
    initialize: function() {...},
    render: function() {...},
    renderFoo: function() {...},
    someVar: {},
});

Sembra che sarebbe più conveniente se tutti usassero approssimativamente gli stessi criteri quando ordinano i loro metodi (se non altro per facilitare la ricerca di cose). Tuttavia, mi chiedo se:

A) che è persino possibile / realistico (o dovrei semplicemente accettare il fatto che tutti avranno un altro ordine)?

B) in tal caso, che tipo di ordinamento dovrebbe essere (l'unica cosa veramente consistente che riesco a pensare è alfabetica, ma sembra meno che ideale)?

    
posta machineghost 23.05.2014 - 22:12
fonte

4 risposte

2

Tutti avranno il proprio standard preferito diverso, ma è importante per tutti mettere da parte il loro ego per il miglioramento del team e attenersi a uno standard coerente.

Le revisioni di codice sono un buon modo per applicare uno standard di codifica.

Quali sono le caratteristiche specifiche dello standard di codifica da parte tua e della tua squadra. Diversi team hanno requisiti diversi e saranno ottimizzati con standard diversi.

È importante concentrarsi su ciò che stai cercando di raggiungere prima di decidere uno standard di codifica.

Il mio team deve essere in grado di scrivere codice velocemente e integrarsi con molte basi di codice ereditate di vario grado di qualità. Di solito il nostro lavoro riguarda l'implementazione di nuove funzionalità o l'estensione di quelle esistenti. Questo significa che abbiamo bisogno di scrivere codice velocemente e che sia facile per chiunque altro nel team essere in grado di prenderlo ed eseguirlo.

A causa di questi requisiti, il nostro codice standard si concentra sulla leggibilità su piccola scala. Il codice che scriviamo dovrebbe generalmente essere breve e mirato e organizzato in un modo che possa essere facilmente cercato. Dato che tendiamo ad avere un numero moderato di stagisti, è anche importante che possiamo addestrarli rapidamente.

Questo significa che abbiamo selezionato un ordinamento alfabetico perché è più veloce da insegnare e abbastanza veloce da scrivere.

Se i tuoi requisiti sono diversi, come la manutenzione a lungo termine con un team di sviluppatori più esperti, ti consiglio una struttura che sia comoda per lavorare. Un esempio potrebbe essere:

For function bodies:

  • directives
  • var declarations
  • function declarations
  • variable initialization
  • main execution

For prototypes:

  • initialization methods
  • API methods
  • event handlers
  • pseudo-private methods
  • etc...

Anche in questo caso, le specifiche dell'ordine dovrebbero essere determinate dalla tua squadra con l'accento sul miglioramento delle prestazioni complessive della squadra. Alcuni team lavorano alla grande quando non devono lavorare con standard formali e altri non possono lavorare senza uno standard rigorosamente applicato e ben documentato.

    
risposta data 24.05.2014 - 01:25
fonte
2

È una questione di politica di squadra, proprio come le convenzioni di denominazione. è una buona idea avere un ordine accettato per motivi di leggibilità, purché la maggior parte delle persone lo segua.

Come dici tu, ci sono un paio di opzioni:

  • Nessun ordine.
  • Proprietà, metodi e campi raggruppati per argomento (cosa, readThing, writeThing, deleteThing ...)
  • Membri raggruppati per comportamento (cosaA, cosaB, readThingA, readThingB, writeThingA, writeThingB)
  • E così via ...

Prima di accettare qualsiasi politica, assicurati che le aspettative su come seguirla siano chiare.

    
risposta data 23.05.2014 - 22:22
fonte
1

Ordino sempre metodi basati sul loro ruolo, metodi critici (solitamente di piccole dimensioni) in basso, metodi che applicano i metodi precedenti in cima. Non ordinarli in ordine alfabetico, in questo modo svanirai indizi che rivelano la coerenza del codice, necessario quando è necessario rifattorizzare il codice.

    
risposta data 23.05.2014 - 23:17
fonte
1

Non penso che funzionerebbe. Dovresti definire era l'ordine era, e quella definizione dovrebbe essere inequivocabile, e dovrebbe anche includere uno standard di denominazione che definisce il nome per ogni funzione possibile perché forse "relaxGraphNodes ()" non dovrebbe andare in lo stesso posto di "evenOutPointSet ()".

Sarebbe un investimento immenso ... l'unico gruppo che ho visto fare qualcosa di simile era il team di sviluppo di Microsoft Office, e ci sono voluti anni per risolvere il tutto e sono finiti con un documento standard di centinaia di pagine.

    
risposta data 24.05.2014 - 05:00
fonte

Leggi altre domande sui tag