Devo mantenere le convenzioni di denominazione errate?

Question

Attualmente sto lavorando su un sito che ha attraversato dio sa quante mani degli sviluppatori. Una delle cose che non mi piace è il modo in cui ogni tabella nel database ha il prefisso "tbl_" e ogni campo "fld_".

Ho iniziato a lavorare su una nuova funzione e mi trovo di fronte al seguente problema: le mie nuove tabelle dovrebbero continuare con la vecchia convenzione o no?

Credo che dovrei, ma mi sento stupido a farlo :)

Answer 1

vorrei mantenere la stessa convenzione .. Indipendentemente se si tratta di cattivo o almeno non sarebbe coerente. E la coerenza sarà molto importante per il prossimo sviluppatore che ottiene il codice.

Answer 2

Vai con quale via mai costa meno, in denaro e risorse. Se non ti farà risparmiare denaro andando a ri-coltivare il terreno, allora non farlo. Stringi i denti e vai avanti.

Answer 3

Se è uno stile costante in tutta l'applicazione, seguirei la convenzione di denominazione che renderà molto più semplice lo sviluppatore successivo.

Answer 4

Tendo a guardare la scala coinvolta. La coerenza di una cattiva convenzione di denominazione, per me, è preferibile su una moltitudine di diversi nella stessa base di codici o database.

Se ci sono una manciata di tavoli e puoi tranquillamente cambiarli, la mia sensazione è di fare il resto. Ma qualsiasi cosa di scala o di un'applicazione su cui stai facendo solo un bugfix probabilmente non vale il tempo e gli sforzi necessari.

Answer 5

"Se non è rotto, non aggiustarlo"

Answer 6

Credo che si dovrebbe preferire coerenza e seguire la convenzione già in uso.

Pensa ai poveri sviluppatori che ti seguono dietro e devi gestire due diverse convenzioni di denominazione (quella originale e quella nuova), nessuna delle quali piace ai nuovi sviluppatori.

Answer 7

Essendo un imprenditore, mi trovo di fronte a questo problema. Ecco i miei 2 centesimi:

Se non è rotto, allora il cliente sta sprecando i loro soldi facendomi cambiare. A meno che non stia riscrivendo l'intera app, di solito mantengo i vecchi (cattivi) standard (almeno in quel modo, non hai parte dell'app con una convenzione e altre parti che usano qualcosa di diverso - questo mantiene il codice leggibile da altri gli sviluppatori).

Answer 8

Benvenuti nel mondo della manutenzione. ;)

Chi dire che la prossima persona che lavora sul sito non disprezzerà il modo in cui hai fatto le cose?

Answer 9

Hai due opzioni.

1. Cambia tutte le convenzioni di denominazione errata a quelle nuove.
2. Utilizzare le vecchie convenzioni.

Qualcuno guarderà più avanti questo codice e dovrà occuparsi di eventuali differenze create. Ciò significa che devi essere consapevole che altre persone sono interessate da questa decisione. Fai la cosa giusta se hai tempo, fai la cosa brutta se non hai tempo ... ma mantienila coerente.

Answer 10

Qualsiasi convenzione di denominazione è migliore di no/convenzione di denominazione incoerente.

Answer 11

Dico cambia se è presente una differenza significativa tra il vecchio codice e il nuovo codice. Ad esempio, se la vecchia via era terribilmente senza via d'uscita e la nuova strada è completamente indipendente, allora vai avanti e inizia una nuova convenzione.

È bello essere visivamente coerenti se il nuovo materiale è strutturalmente e semanticamente coerente, ma se quello che stai facendo è una rottura netta da ciò che è venuto prima, allora è ancora più importante che le cose diverse appaiano diverse.

Answer 12

Come tutti hanno detto, stare con la convenzione cattiva in quanto non si sta scrivendo da zero. Tuttavia, usa "buone pratiche" se c'è un bisogno impellente di farlo (altrimenti l'utente finale sarà influenzato negativamente altrimenti). Ad esempio, se la "cattiva convenzione" rende gli utenti dell'API utilizzare la boxe, modifica in gran misura il valore delle stringhe e altre prestazioni; non aggiungere al problema! L'obiettivo finale del software e delle API non è quello di semplificare la vita degli sviluppatori; ma l'utente finale. Gli sviluppatori che rimangono nel business a lungo sono altamente consapevoli di questo e tu vuoi essere uno di quegli sviluppatori.