Perché la seguente linea guida per la denominazione è diversa tra le lingue OO e non OO?

Per la situazione non OO PrintDocument() : il suffisso Documento ti fornisce il contesto richiesto per sapere che il metodo deve essere chiamato con un parametro Document .

Per la situazione OO doc.Print() : l'oggetto doc ti offre già un contesto. Vale a dire, che i suoi metodi eseguiranno azioni su Document . Poiché il contesto è quasi esplicito, sarebbe ridondante specificare "Documento" nel nome del metodo.

E scrivi la tua seconda domanda: sto assumendo che Print(doc) non sia raccomandato perché è più difficile scoprire esattamente cosa fa Print . Immagino che si tratti di presentare quante più informazioni possibili il prima possibile. Codice di auto-documentazione!

Il problema con domande come queste riguarda il fatto che stai parlando dello stile di codifica e NON del codice stesso; non c'è nulla di intrinsecamente sbagliato in questo tipo di domande (ho avuto dibattiti con colleghi sullo stile "appropriato" per anni), ma entra nel regno di "come dovrei nominare le mie funzioni per chiarire al meglio all'utente cosa fanno" .. CHE è completamente a tuo carico il programmatore. È completamente possibile avere un oggetto (nel realm OO) che crea sia un Print che PrintDocument (forse la funzione Print gestisce alcune cose semplici per te che PrintDocument non fa, o forse Print stampa qualcosa sullo schermo anziché sulla stampante). Il punto è che le linee guida per la denominazione sono solo questo, linee guida.

Dove questo tipo di convenzioni di denominazione fanno davvero la differenza è nel mondo procedurale (non OO) e più specificamente nella lingua C , che, come già sottolineato da un utente, non supporta gli overload di funzioni (ovvero 2 funzioni denominate uguali ma con parametri diversi, es: void Print(void) e void Print(int) non riuscirebbero in C ). In questo caso in cui il linguaggio stesso ti inibisce dal fare tali cose da quando segue una sorta di convenzione. Inoltre, quando hai a che fare con la programmazione orientata agli oggetti, di solito stai parlando di oggetti con stato, a quel punto le funzioni di solito diventano verbi dell'oggetto (cioè ho un oggetto Image , vorrei stamparlo, quindi Chiamo img.Print() che agisce sull'oggetto Image che ho .. OO e non-OO non sono così diversi perché lo stesso potrebbe essere detto per PrintImage(Image) ), le linee guida di stile sono più su COME il codice che stai la scrittura viene trasmessa all'utente e di solito fa parte del processo di "progettazione" nello SDLC.

Sono stato in entrambi i kernel Linux / Unix, ambienti embedded e cloud, Java e .NET e non ho MAI visto uno stile unico da allora. Dipende SEMPRE dalla portata del progetto, dal team, dalla lingua, dall'intenzione e da IMHO se lo sviluppatore ha dormito abbastanza la sera prima :) E anche se non puoi sempre fare affidamento sulla documentazione, trovo che se è disponibile può dare una migliore comprensione di cosa dovrebbe fare una funzione rispetto al nome della funzione stessa (i codici del kernel e i nomi delle API possono essere MOLTO confusi se si sta solo andando fuori dai nomi).

Spero che possa aiutarti

Se leggo "Stampa (doc)" il mio primo istinto è di assumere che la funzione chiamata stampa il contenuto di doc nella console.

PrintDocument d'altra parte dà l'impressione che il documento venga effettivamente stampato dalla stampante.

In qualsiasi tipo di programmazione, è utile avere identificatori semanticamente suddivisi in gruppi in base al tipo di cose su cui operano. In un framework orientato agli oggetti, gli identificatori per diversi tipi sono intrinsecamente suddivisi in diversi gruppi indipendentemente da come vengono chiamati, ma in un framework non orientato agli oggetti il sistema raggruppa tutti gli identificatori. Se i nomi non includono qualcosa per identificare a quale parte del programma appartengono, può essere difficile tenere traccia di quale tipo usa delete , che usa free , che usa release , che usa close , che utilizza shutdown , ecc., mentre se le funzioni sono invece denominate DeleteDrawingContext , FreeMemHandle , ReleaseLock , CloseFile , ShutdownSocket , sarebbe molto più chiaro. Le cose potrebbero essere più chiare se avessero usato verbi simili (dato che non sarebbe stato necessario rendere i verbi unici per evitare di nominare collisioni).

Vale la pena notare che alcune persone preferiscono prefissare il nome dell'identificatore con un tag relativo al sottosistema che li definisce (ad esempio, gli identificatori relativi al sottosistema Foo Manager potrebbero essere FM_Create, FM_Release, ecc.) Tale uso non è necessario in lingue in cui è possibile suddividere logicamente gli spazi dei nomi, ma può essere utile in quelle in cui tutto viene raggruppato in uno spazio dei nomi globale. Nota che non importa se tutti seguono la convenzione; se metà degli identificatori ha prefissi e metà no, la presenza o l'assenza di un prefisso può diventare di per sé un'indicazione del sottosistema che definisce un identificatore.