Ha senso utilizzare "ys" anziché "ies" negli identificatori per facilitare la funzionalità di ricerca e sostituzione? [chiuso]

9

Sebbene grammaticamente scorretto, quando si scrivono identificatori per funzioni, variabili, ecc. ha senso semplicemente aggiungere una "s" ai plurali delle parole che terminano in Y? La mia ragione è che se hai bisogno di trovare e sostituire, ad esempio, sostituendo "azienda" con "fornitore", "azienda" corrisponderebbe a forme sia singolari che plurali (" azienda e " azienda s"), mentre se il plurale fosse stato digitato correttamente, dovresti effettuare due ricerche separate.

    
posta SHNC 27.07.2015 - 14:40
fonte

3 risposte

24

Qualsiasi ricerca e sostituzione dovrebbe essere eseguita con attenzione e ogni modifica deve essere controllata manualmente per evitare ad esempio "accompagnare" in un commento che diventa "spettatore" con la società / il fornitore cambia. Pertanto, due ricerche separate per "società" e "società" non dovrebbero creare un sovraccarico significativo rispetto al tempo speso a ispezionare e approvare ogni modifica.

Quindi le parole errate per ottenere una sola ricerca offrono gli aspetti negativi di un aspetto negativo e sono più difficili da leggere di quanto non sia necessario, senza offrire alcun vantaggio evidente.

    
risposta data 27.07.2015 - 14:52
fonte
6

Suppongo che tu stia parlando della ridenominazione nei file del codice sorgente. Con gli IDE di oggi questo dovrebbe sempre essere eseguito con gli strumenti di refactoring dell'IDE. Se il tuo IDE non ha questo, prova a passare a un altro IDE. La maggior parte degli strumenti di refactoring di IDE mantiene anche una cronologia del refactoring, dandoti la possibilità di "annullare" rapidamente se non ti piacciono i risultati del refactoring. Usando la ricerca / sostituzione, potresti non avere la possibilità di annullare l'intera serie di modifiche (a meno che tu non usi gli strumenti di controllo di revisione e di ripristinare la versione precedentemente impegnata). Inoltre, utilizzando gli strumenti di refactoring sei più sicuro di modificare inavvertitamente qualcosa che non intendevi modificare.

    
risposta data 27.07.2015 - 21:58
fonte
-9

Sì! Sì! Sì! Ha perfettamente senso farlo. E lo sto facendo da anni.

Divulgazione 1: l'inglese non è la mia lingua nativa.

Disclosure 2: La mia conoscenza della grammatica inglese è considerevolmente migliore di quella del madrelingua medio.

Disclosure 3: Quando si tratta di comunicare con gli umani, io sono una grammatica veemente nazista.

E ora che queste rivelazioni sono fuori mano, lasciatemi dire che la grammatica inglese non ha spazio nel codice. Vedete, è per questo che si chiama code e non prose . Si suppone che abbia qualche somiglianza con un linguaggio compreso dagli umani, ai fini della leggibilità, ma a parte ciò, ciò di cui abbiamo maggiormente bisogno dal codice non sono le qualità della prosa; sono altre qualità più tecniche, come precisione , ambiguità e tersezza . Ecco perché la sintassi C di if( x != y ) y++; è preferibile molto alla sintassi IF X IS NOT EQUAL TO Y THEN ADD 1 TO Y END-IF. di Cobol. La presunta desiderabilità di compilatori che capiscono il linguaggio naturale è un errore, e non credetemi, vedete cosa ha da dire su questo l'Older: Edsger W. Dijkstra, Sulla follia della "programmazione in linguaggio naturale" .

Un'altra qualità che è importante è computabilità degli identificatori . Il fatto che una proprietà chiamata Color possa sempre essere letta tramite un metodo chiamato getColor() e scritta tramite un metodo chiamato setColor() è di fondamentale importanza. Questi identificatori sono calcolabili dal nome della proprietà, quindi non devi conoscerli a memoria. Se un programmatore scegliesse un paio di metodi chiamati getColor() da una parte, ma colorize() dall'altra, i loro colleghi avrebbero giustamente considerato questo sabotaggio. Ecco quanto è importante la computabilità dell'identificatore.

Inoltre, è possibile scrivere strumenti di programmazione (e molti di essi sono stati scritti, ad esempio, Hibernate ) che possono calcolare questi nomi. Senza la computabilità del nome dell'identificatore, è necessario utilizzare la sintassi aggiuntiva (ad es. In Hibernate, annotazioni aggiuntive) per specificare precisamente su ciascuno strumento come creare ogni singolo nome identificativo o precisamente quale nome ad hoc è stato assegnato a ciascuna entità.

Quindi, la computabilità dell'identificatore è importante, mentre allo stesso tempo la grammatica inglese è irrilevante, (dato che non stiamo facendo programmazione in linguaggio naturale), così da essere in grado di calcolare il nome di una raccolta di entità con sempre aggiungere "s" al nome di una singola istanza ha perfettamente senso, non importa il fatto che viola la sensibilità della lingua inglese della maggior parte delle persone (inclusa la mia).

E che ci piaccia o no, questa è la tendenza del futuro. La lingua madre della maggior parte dei programmatori del pianeta non è più l'inglese, e la tendenza è continuare molto strong in questa direzione. (Inoltre, non sarei nemmeno disposto a scommettere sul suggerimento che l'inglese è la lingua madre della maggior parte dei programmatori che lavorano negli Stati Uniti in questo momento.) Queste sono persone che, in larga misura, quando cercano di calcolare il nome di una raccolta dal nome di una singola istanza di "azienda", semplicemente aggiungerà una "s", e la forma "aziende" non verrà nemmeno in mente. Per una grande e sempre crescente percentuale di programmatori nel mondo, la conoscenza delle peculiarità della lingua inglese non aggiunge alcun valore al loro lavoro, ma lo rende solo leggermente più difficile.

    
risposta data 27.07.2015 - 16:32
fonte

Leggi altre domande sui tag