Odio uno dei nostri standard di codifica e mi fa impazzire, come elaborarlo? [chiuso]

Se vuoi superarlo - c'era una citazione di Torvalds:

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Considerate ora, dove mettono i programmatori che si preoccupano di una cosa così secondaria come lo stile di rinforzo imposto dal loro codice standard? La tua base di codici è così incontaminata che il rinforzo è l'unico problema che vale il tempo di discutere?

A qualcuno piace a modo tuo e altre no. In entrambi i casi qualcuno sarà infastidito. E 'solo il tuo turno questa volta. Succhialo e vai avanti con il lavoro.

Lo standard del team è documentato? Se lo è, ci sono dei motivi nella guida allo stile? Onestamente, ho dovuto risucchiare un sacco di volte e ottenere un vero lavoro. Ci sono problemi peggiori da avere, ma ti sento - è ancora in classifica (sono d'accordo con te sullo stile, comunque).

Cosa mi ha aiutato a superarlo:

1. Realizzato che ci sono benefici reali per un singolo stile (non importa quale sia). O almeno un gruppo di persone la pensa così .
2. Esattamente quello che hai appena fatto, scrivi perché è sbagliato, quindi puoi postulare la discussione in futuro.
3. Usa uno strumento per lo styling per l'amor di dio , salverà la tua sanità mentale. Resharper , CodeMaid , StyleCop , JSLint , CheckStyle , ecc. ... anche Visual Studio lo farà per te .
4. Prendi il culo su questo progetto e preparati per il prossimo quando puoi impostare gli standard.

La superiorità di una convenzione rispetto all'altra è * chiaramente arbitraria * .

I problemi di leggibilità che affronti o che i tuoi compagni di squadra dovrebbero affrontare con i tuoi standard, sono solo una resistenza psicologica al cambiamento.

L'argomento di leggibilità obiettiva è a favore di * consistenza * sull'intero codice base.

Pensa a un momento in cui eri sicuro di avere ragione su qualcosa e in un periodo di tempo hai capito che ti sbagliavi, o almeno che stavi esagerando in tutti quegli anni. Considera la possibilità che tu possa sbagliarti di nuovo e dare il nuovo standard di codifica o il tempo di elaborazione per convincerti.

I miei stessi standard infuriano quando ero abbastanza nuovo nella codifica (diciamo cinque anni nella mia carriera) era se gli identificatori multiword dovessero essere WrittenLikeThis o written_like_this . Non dirò nemmeno quale sia, ma il punto è che dopo un po 'di tempo ho cambiato le parti e dopo un po' di tempo in più non mi importava affatto.

La differenza standard che stai descrivendo con le parentesi graffe è in gran parte arbitraria. Entrambi i modi sono ugualmente buoni e per un'azienda, a patto che tutti lo facciano lo stesso.

Il "chiaramente superiore" di cui stai parlando è il tipo di superiorità di cui la gente parla quando parla di cose "a cui sono abituati".

Ci si abituerà presto e in un anno o giù di lì, l'altro modo sarà "chiaramente superiore".

Quindi in breve: gestiscilo.

Questo particolare argomento equivale a una guerra religiosa tra coloro che preferiscono uno stile piuttosto che l'altro. Pochissime persone sono ambivalenti ...

In fin dei conti, nessuno dei due ha ragione e nessuno dei due è sbagliato.

Le guide di stile e gli standard di codifica esistono per una serie di motivi - e un aspetto chiave è garantire l'uniformità del layout, che mira a ridurre il numero di errori evidenti e a migliorare la manutenibilità.

Am I the only one that struggles with an opinionated stance against a specific standard?

La risposta breve è "No", non sei l'unico. Ma ci sono cose più importanti di cui preoccuparsi. Anche negli standard a cui uno ha contribuito, ci sarà sempre un compromesso - testimonia alcuni degli aspetti che hanno reso C99 e C12 che non hanno senso per me.

Anche MISRA-C (su cui ho un'influenza diretta) contiene elementi che personalmente non sono d'accordo - ma posso capire perché gli altri sentano la giustificazione.

how have you gotten over these?

E qui sta la risposta - piuttosto che concentrarsi sul motivo per cui non ti piace personalmente, cerca di capire perché la persona / le persone che hanno acconsentito lo facesse.

Normalmente le regole vengono introdotte (in una porta di chiusura della stalla dopo che il cavallo si è imbullonato in qualche modo) per risolvere un problema precedente. E se la regola è ancora priva di senso, parla con il proprietario standard e prova a "educarli".

Am I the only one that struggles with an opinionated stance against a specific standard?

Certo che no. Le riunioni per determinare gli standard di codifica sono orribili! Si trascinano per ore e i partecipanti diventano personalmente investiti nell'ottenere le proprie idiosincrasie preferite (e invariabilmente sbagliate, tranne le mie) contenute nello standard. Alla fine, nessuno è soddisfatto del risultato. Se qualcosa può essere peggio degli incontri sugli standard di codifica, sono gli incontri formali di revisione del codice nei diversi mesi che seguono la determinazione dello standard: alcune persone cercano di adottare lo standard, mentre altri (intenzionalmente o meno) lo ignorano, e si ottiene ore di feedback come: Sulle righe 132, 142, 145, 181, 195 e 221 di SillyFileConverter.cpp si mette la parentesi aperta sulla stessa riga quando lo standard di codifica dice chiaramente che dovrebbe essere su seguendo la linea!

how have you gotten over these?

A modo loro, gli incontri aiutano. Anche se provate simpatia per il tipo che ha lasciato il tutore di apertura sulla stessa linea del condizionale, o qualsiasi altra cosa, sarete comunque infastiditi da lui per aver sprecato il vostro tempo non solo risucchiandolo e seguendo lo stupido standard. Se il ragazzo è un imbroglio e fa la stessa cosa più e più volte, diventa ancora più fastidioso. Essere infastiditi da quel comportamento rende molto più facile giustificare la scrittura in uno stile che è un po 'diverso da quello che preferiresti: non vuoi essere quel tipo , dopotutto.

Anche se non sei sottoposto a interminabili revisioni formali del codice, puoi provare a rivedere il tuo codice specifico per la conformità allo standard. Non importa ciò che pensi dello standard, stai solo confrontando ciò che hai scritto con ciò che dice lo standard. Se ti lamenti ogni volta che non rispetti, ciò potrebbe fornire alcuni dei feedback negativi di cui hai bisogno per aiutarti ad adottare lo standard.

Penso che tu debba solo andare avanti. Cercherò di indirizzare i tuoi appunti con le mie opinioni:

• Codice Bloats

  Una riga di codice in più non è affatto un codice di rigonfiamento, a meno che non si stiano scrivendo centinaia di metodi in una singola classe, che aggiungerà centinaia di linee aggiuntive. Poi di nuovo se hai centinaia di metodi in una singola classe hai un altro problema.

• Più difficile da digitare

  Non posso più essere in disaccordo con te, devi comunque premere il tasto Invio per passare alla riga successiva. Che dire è più difficile da digitare?

• Più difficile da leggere

  Mi sento come se ogni linea in un pezzo di codice dovesse avere una funzione specifica. Di seguito è necessario definire il nome del metodo in una riga, quindi le parentesi aperte e chiuse sulle proprie righe separate.

• Utilizzato da persone che provengono da uno sfondo di IDE MS

  Uhh ..... ok?

In sintesi sembra che tu stia facendo il pignolo di essere uno sviluppatore .Net rispetto a qualsiasi altro tipo di sviluppatore come se fosse inferiore perché hanno usato un IDE che ha come valore predefinito questo standard.

Con questo genere di cose ricordo Gulliver a Lilliput. I lillipuziani avevano combattuto una guerra per cui finiva di aprire un uovo sodo. (L'originale big endian, little endian fight).

Prendilo come un'opportunità per ridere di te stesso, in realtà non sono abbastanza frequenti negli affari.

Il tuo esempio particolare è sfortunato in quanto è uno con cui alcuni saranno d'accordo e altri no. Non sono d'accordo con i tuoi argomenti contro, ad esempio, e sono sicuro che lo faranno anche molti altri, così come sono sicuro che molti altri saranno d'accordo con loro. Mi fa quasi pensare che la domanda debba essere chiusa perché è così soggettiva.

Tuttavia, la domanda su come comportarsi con uno standard con cui non sei d'accordo è più comprensibile. Penso che la risposta sia che le linee guida per lo styling esistono e sono state accettate e sono state utilizzate, quindi la risposta è solo per sorridere, sopportare e solo occuparsene. Considera che avere coerenza è più importante. Se le linee guida sono imprecise o sbagliate, può esserci un argomento per il cambiamento, ma questo è stilistico, quindi non ci sono argomenti a parte le preferenze personali.

Originario originario di Java, seguivo lo standard che hai menzionato. Poi mi sono spostato su altri C ++ e C # in cui viene usato lo stile che odi. Ma non ha una risposta giusta o sbagliata. Ciò che è più importante è avere uno standard seguito da tutti. Se uno standard di codifica è stilistico come questo e non è chiaramente sbagliato, provare a litigare causerà solo attriti nella squadra.

Un formatter + check in hook è un buon inizio. Ma non è abbastanza, dal momento che ciò che scrivi non è importante quanto quello che fissi tutto il giorno. In alcune situazioni, l'approccio della modalità Occhiali di Emacs - mantiene i file nel loro stile ma si mostra più vicino al tuo stile - è attraente.

La mia esperienza con esso - affrontando esattamente il problema per cui è stata scritta, CamelCaps vs underscore_separated - è che è diventato rapidamente più fastidioso che utile, ma per un paio di settimane ha semplificato la mia transizione verso (a malincuore) accettando il stile della compagnia, oltre a fornire uno sbocco per incanalare la mia rabbia ("ah lo odio, lascia che aggiusti di nuovo le impostazioni ... lì, almeno ho fatto qualcosa "); -)

In ogni caso, la modalità Occhiali non gestisce il posizionamento delle graffe, probabilmente non usi Emacs e non leggi il codice esclusivamente nel tuo editor :-(
Ma l'ultimo punto è anche un'opportunità: se tu leggi codice la maggior parte del tempo in uno strumento separato, puoi modificarlo per convertire gli stili senza preoccuparti del rumore di riformattazione di andata e ritorno, perché è di sola lettura ! In particolare, se leggi codice in alcune interfacce Web, utilizza Greasemonkey.

Ecco alcune idee più semplici per mitigazione lieve:

• Scegli un carattere più ampio ma non così alto, per recuperare le linee dello schermo perse.

  • Utilizza schermo intero più spesso, se disponibile.

• Imposta le parentesi graffe da evidenziare con un colore sottile (e un carattere più piccolo?), rendendole meno visibili rispetto al resto del codice. L'indentazione dovrebbe essere sufficiente per leggere, esp. con lo spazio vuoto da { righe ...

• Assicurati che il tuo editor evidenzi la corrispondenza tra parentesi graffe aperte quando hai superato } - potrebbe aiutarti un po 'quando i tuoi occhi si spostano istintivamente nel posto sbagliato.

• Ri "difficile da digitare": ottieni un vero editor, configuralo per aprire automaticamente una nuova riga quando premi { .

Vivi con esso.

Questo è chiaramente cosmetici e non cambia nulla sulla qualità del codice o sulla tua produttività come sviluppatore. Niente vale la pena iniziare un argomento.

Per quel tipo di standard di codifica, selezionerei la coerenza attraverso la base di codice e la leggibilità su qualsiasi approccio "religioso" (persino ben motivato) ogni giorno.

Pensare a una decisione democratica della maggioranza dei membri del team su un problema non molto importante può aiutarti a superare il problema.

È lo standard:

link

La maggior parte di quelli che dicono "è lo standard" seguono il principio "cinque scimmie".

Vai avanti e usa lo stile che desideri. Quindi utilizza alcuni codice beautifier per modificare il codice in formato standard o direttamente piccola applicazione che convertirà il codice dal tuo stile allo stile standard specificato. Usa l'abbellitore prima di verificare il codice.
Puoi anche fare il contrario per cambiare il codice archiviato dal formato standard al tuo formato, quando ci stai lavorando.