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

Disclaimer : non esagerato come suggerisce il titolo, ma mi mette ancora a disagio. Ho intenzione di esprimere onestamente, quindi prendilo con un granello di sale. Fai solo finta di parlare di quello standard di codifica con cui non ti piace lavorare.

Modifica : il fatto che non mi piaccia, non significa che non lo uso o non lo impongo.

Ho deciso di porre questa domanda nello spirito di come superare uno standard che non ti piace, non ottenere aiuto su come meglio discutere su come può essere modificato (anche se ogni commento su quest'ultima parte è apprezzato). Inoltre, lavoro in una grande azienda e un tale cambiamento di qualcosa che ha vissuto per così tanto tempo e che conta così poco è improbabile.

Lo standard è lo standard di apertura-parentesi graffa-su-linea dedicata:

somefunction()
{
    //...
}

Invece del * chiaramente superiore * (notare il tono scherzoso / frustrato):

somefunction() {
    //...
}

I miei argomenti personali contro lo standard:

• Gonfia il codice : linee extra inutili
• Più difficile da scrivere : anche se probabilmente questo è solo io alle prese con lo standard, so che un tasto in più non è poi così male.
• Non più facile da leggere : inizio a leggere una dichiarazione di funzione, un'istruzione if o qualsiasi altra istruzione di impilamento dell'ambito e già non devo cercare una parentesi graffa di apertura. I blocchi nidificati con questo standard mi fanno arrabbiare solo per qualche motivo.
• Utilizzato da persone che provengono da un ambiente IDE Microsoft : penso che ci dovrebbe essere una ragione argomentata (o più) dietro uno standard, non solo accettarlo dal paradigma.

I loro argomenti (e il mio modo di replicare internamente a loro):

• Più facile da leggere perché puoi vedere dove iniziano e finiscono subito i blocchi : non riesco a capirlo, a che serve il blocco se non sai di cosa è di proprietà, quindi devi leggere al contrario.
• L'ho usato in un IDE di Microsoft e mi è piaciuto : Uhh ... ok?
• È nello standard : * crepe *

Sono l'unico che lotta con una posizione supponente nei confronti di uno standard specifico? Come li hai superati? Qual è la tua opinione su come dovrebbe essere questo particolare standard (solo per divertimento)?

Se vuoi superare questo, c'era una citazione di Torvalds:

I programmatori sbagliati si preoccupano del codice. I buoni programmatori si preoccupano delle strutture di dati e delle loro relazioni.

Ora considera, dove mettono i programmatori che si preoccupano di una cosa così piccola come lo stile di rinforzo applicato dal loro standard di codice? La tua base di codice è altrimenti così incontaminata che il controvento è l'unico problema su cui vale la pena discutere?

Ad alcune persone piace a modo tuo, altre no. Ad ogni modo qualcuno sarà infastidito. Questa volta è solo il tuo turno. Succhiarlo e andare avanti con il lavoro.

Lo standard del team è documentato? In tal caso, ci sono delle ragioni nella guida di stile? Onestamente, ho dovuto succhiarlo un sacco di volte e fare 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 vantaggi 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é ti sembra sbagliato, in modo da poter sostenere bene l'argomento in futuro.
3. Usa uno strumento di styling per l'amor di Dio , salverà la tua sanità mentale. ReSharper , CodeMaid , StyleCop , JSLint , CheckStyle , ecc ... anche Visual Studio lo farà per voi .
4. Dai un calcio a questo progetto e sii pronto per il prossimo quando puoi stabilire gli standard.

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

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

L'argomento obiettivo della leggibilità è a favore di * coerenza * sull'intera base di codice.

Ripensa a un'epoca in cui eri sicuro di avere ragione su qualcosa e in un periodo di tempo hai capito che avevi torto, o almeno che stavi reagendo in modo esagerato tutti quegli anni fa. Considera la possibilità che potresti sbagliare di nuovo e dai il nuovo standard di codifica o il tempo di elaborazione per convincerti.

I miei standard di rabbia quando ero abbastanza nuovo nella programmazione (diciamo cinque anni dopo la mia carriera) erano se gli identificatori di parole multiple dovrebbero essere WrittenLikeThiso written_like_this. Non dico nemmeno quale ho cestinato, ma il punto è che dopo un po 'di tempo ho cambiato parte e dopo un po' di tempo in più non mi importava in alcun modo.

La differenza standard che stai descrivendo con le parentesi graffe è in gran parte arbitraria. Entrambe le strade sono ugualmente buone e per un'azienda, purché tutti facciano lo stesso, va tutto bene.

Il "chiaramente superiore" di cui stai parlando è il tipo di superiore di cui le persone parlano quando parlano di cose a cui "sono abituati".

Ti abituerai abbastanza presto e tra circa un anno, l'altro modo sarà "chiaramente superiore".

Quindi in breve: affrontalo.

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

Alla fine, nessuno dei due ha ragione e nessuno dei due ha torto.

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

Sono l'unico che lotta con una posizione supponente contro uno standard specifico?

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

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

come hai superato questi?

E che sta qui la risposta - piuttosto che concentrarti sul perché non ti piace personalmente, cerca di capire perché la persona / le persone che hanno concordato lo hanno fatto.

Le regole vengono di solito introdotte (in una porta della stalla di chiusura dopo che il cavallo ha scappato via) per risolvere un problema precedente. E se la regola è ancora priva di senso, parla con il proprietario standard e cerca di "educarli".

Penso che devi solo andare avanti. Cercherò di affrontare i tuoi appunti con le mie opinioni:

• Codice Bloats

  Una riga aggiuntiva di codice non è affatto un codice gonfio, a meno che tu non stia scrivendo centinaia di metodi in una singola classe, che aggiungerà centinaia di righe extra. Quindi di nuovo se hai centinaia di metodi in una singola classe hai un altro problema del tutto.

• Più difficile da scrivere

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

• Più difficile da leggere

  Sento che ogni riga di un pezzo di codice dovrebbe avere una funzione specifica. Successivamente, è necessario definire il nome del metodo in una riga, quindi le parentesi graffe aperte e chiuse su righe separate.

• Utilizzato da persone che provengono da un background IDE MS

  Uhh ..... ok?

In sintesi, sembra che tu stia pignolando l'idea di essere uno sviluppatore .Net al contrario di qualsiasi altro tipo di sviluppatore come se fosse inferiore perché usavano un IDE che per impostazione predefinita è questo standard.

Sono l'unico che lotta con una posizione supponente contro uno standard specifico?

Ovviamente no. Le riunioni per determinare gli standard di codifica sono orribili! Si trascinano per ore e i partecipanti vengono investiti personalmente per ottenere le proprie idiosincrasie preferite (e invariabilmente sbagliate, tranne la mia). Alla fine, nessuno è soddisfatto del risultato. Se qualcosa può essere peggio del rispetto degli standard di codifica, sono i meeting formali di revisione del codice nei vari mesi che seguono la determinazione dello standard: alcune persone cercano di adottare lo standard, mentre altri (intenzionalmente o no) lo ignorano e si ottiene ore di feedback come: Sulle righe 132, 142, 145, 181, 195 e 221 di SillyFileConverter.cpp si inserisce la parentesi graffa di apertura sulla stessa riga quando lo standard di codifica dice chiaramente che dovrebbe essere sulla riga seguente !

come hai superato questi?

A modo loro, gli incontri aiutano. Anche se simpatizzi completamente con il ragazzo che ha lasciato la parentesi graffa sulla stessa linea del condizionale, o qualsiasi altra cosa, ti irriterai comunque per aver perso tempo non solo succhiandolo e seguendo lo standard stupido. Se il ragazzo è un ciarlatano e fa sempre la stessa cosa, diventa ancora più fastidioso. Essere infastiditi da quel comportamento rende molto più facile giustificare la scrittura in uno stile leggermente diverso da quello che preferiresti , dopotutto non vorrai certo essere quel ragazzo .

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

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

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

Il tuo esempio particolare è sfortunato in quanto è concorde con alcuni e altri no. Non sono d'accordo con le tue argomentazioni contro, ad esempio, e sono sicuro che lo saranno 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 in quanto è così soggettiva.

Tuttavia, la domanda su come trattare uno standard con cui non si è d'accordo è possibile più rispondente. Penso che la risposta sia che laddove esistono e sono state concordate e utilizzate linee guida per lo styling, la risposta è solo quella di sorridere, sopportarla e affrontarla. Considera che avere coerenza è più importante. Se la linea guida è imprecisa o errata, ci può essere un argomento per il cambiamento, ma questo è stilistico, quindi non esiste alcun argomento a parte le preferenze personali.

Venivo da un background Java originariamente quindi ho seguito lo standard che hai citato. Poi sono passato a più C ++ e C # dove viene utilizzato 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 argomentare causerà attrito nella squadra.

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

La mia esperienza con esso - affrontando esattamente il problema per cui è stato scritto, CamelCaps vs underscore_separated- è stata che è diventata rapidamente più fastidiosa che utile, ma per un paio di settimane ha agevolato la mia transizione all'accettazione (a malincuore) dello stile dell'azienda, oltre a fornire uno sbocco per incanalare la mia rabbia ("ah lo odio, fammi regolare di nuovo le impostazioni ... lì, almeno ho fatto qualcosa ") ;-)

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

Ecco alcune idee più semplici per mitigare lieve:

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

  • Utilizza lo 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. Il rientro dovrebbe essere sufficiente per la lettura, esp. con lo spazio vuoto da{ linee ...

• Assicurati che il tuo editor evidenzi la parentesi graffa corrispondente quando sei finito }- potrebbe aiutare un po 'quando i tuoi occhi istintivamente vanno nel posto sbagliato.

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

Convivici.

Questo è chiaramente un cosmetico e non cambia nulla sulla qualità del codice o sulla tua produttività come sviluppatore. Non vale la pena ricominciare una discussione.

Per quel tipo di standard di codifica, sceglierei coerenza tra la base di codici e leggibilità su qualsiasi approccio "religioso" particolare (anche ben ragionato) ogni giorno.

Pensarlo come una decisione democratica della maggioranza dei membri del team su un problema non così importante può aiutarti a superarlo.

È lo standard:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

La maggior parte del detto "è lo standard" sta seguendo il principio "cinque scimmie".

Vai avanti e usa lo stile che desideri. Quindi utilizzare un codice di abbellimento del codice per modificare il codice in formato standard o correggere la propria piccola applicazione che convertirà il codice dal proprio stile allo stile standard indicato. Usa il beautifier prima di controllare il codice.
Puoi anche fare il contrario per cambiare il codice archiviato dal formato standard al tuo formato, quando ci lavori.