Quali argomenti ci sono per usare uno stile di codifica per ogni lingua distinta? [duplicare]

Direi se i tuoi sviluppatori Java programmano regolarmente in C # e viceversa, potrebbero avere qualche argomento per renderli uguali (leggermente più facili da leggere).

Ma anche in questo caso, le differenze possono essere abbastanza utili da trionfare sulla facilità di lettura. Per prima cosa mi piace usare le parentesi aperte della stessa riga in JavaScript per ricordare al mio cervello in ogni momento che il codice che sto guardando non è C #.

Altrimenti, non sono affari loro quelli che usano gli sviluppatori di C #.

Al contrario, è importante che gli sviluppatori di C # mantengano le convenzioni che sono facili da interagire con altri sviluppatori C #, leggere e pubblicare codice C # online, ecc.

I buoni candidati saranno riluttanti ad accettare un'offerta di lavoro in un luogo con un'errata applicazione errata delle convenzioni di codifica.

Esiste un caso per stili diversi per ogni lingua - ti aiuta a ricordare che stai scrivendo qualcosa di diverso, e quindi ti aiuterà a prevenire alcuni sottili errori dovuti a somiglianze linguistiche (cioè dove stai ancora pensando alle tecniche Java quando scrivi Codice C # e vice-versa).

Può rallentarti un po 'quando si passa, ma francamente - questa è una buona cosa. Interrompere l'interruttore di contesto è meglio che immergersi e programmare senza la dovuta attenzione.

Personalmente, vado sempre con "lo stile in cui è scritto attualmente il codice è lo stile da usare". Di tanto in tanto, quando lavoro su certi codici di terze parti che hanno usato un particolare linguaggio, mantengo quello stile terribile.

Purtroppo, non penso che ci sia un modo per raggiungere il tuo obiettivo. Il tuo posto di lavoro ha reso Java la lingua e la cultura di prima classe, e reso C # di seconda classe. Cercare di sollevare questo problema ti renderà probabilmente una persona sfavorevole tra i colleghi.

Questo particolare stile di codifica può anche avere il sostegno di alcuni alti dirigenti della compagnia. Dato che il posto di lavoro è già pieno di politica, sollevare questo problema da solo può essere dannoso per la propria carriera.

Inoltre, per una base di codice che è interamente interna a una società, è possibile scegliere stili di codifica puramente estetici per andare contro la norma del settore, a patto che venga applicata coerentemente. (Dicendo che è cosmetico, significa che lo stile è innocuo per la qualità del codice). Poiché la coerenza è importante, prevale lo stile di codifica esistente, quindi il tuo obiettivo non sarà raggiungibile.

Tuttavia, se l'azienda fa un uso massiccio del codice sorgente di terze parti, mantenere la coerenza di denominazione in ogni lingua diventerà più difficile. (Questa difficoltà non influisce sulle parentesi graffe perché i suoi effetti non sono visibili sulla superficie di un'API (interfaccia di programmazione).)

Se la base di codice della società non utilizza affatto il codice sorgente di terze parti (che potrebbe essere vero per alcune società sufficientemente grandi), o se il team decide di scrivere wrapper per ogni singolo componente di terze parti in modo da normalizzare il denominazione del metodo in base allo standard interno (che è anche una pratica comune in molte aziende), quindi l'uso pesante del codice sorgente di terze parti non fornirà una valida motivazione per seguire la convenzione di denominazione del settore.

Quando tutto sommato, la mia inclinazione è che la risposta di Ewan è l'unica applicabile alla tua situazione, e che altre persuasioni saranno probabilmente sconfitte in un dibattito logico.

A parte tutto, c'è un aspetto tecnico quando è coinvolto JNI. (JNI è usato per consentire al codice Java di chiamare nel codice C ++. Poiché entrambe le lingue sono menzionate da OP, è probabile che JNI sia sul radar quando viene redatto lo standard di codifica della società.)

JNI richiede che i punti di ingresso del metodo nativo C / C ++ vengano nominati in un modo particolare. Questo viene applicato dal runtime Java, che concatenerà il nome della classe Java e il nome del metodo in un modo prescritto, quindi cerca il punto di ingresso JNI. Per questo motivo, è possibile che gli sviluppatori che lavorano sui componenti JNI debbano prescrivere una convenzione di denominazione che deve essere applicata sia ai metodi Java sia alle controparti C ++.