È sbagliato utilizzare gli stessi nomi di classe o di idioma di un'API di terze parti che stai utilizzando?

Naviga le tue risposte
4

FlashPunk è un'API grafica di terze parti per lo sviluppo di giochi semplici in AS3, e prendono ciò che effettivamente sono sprite o oggetti di visualizzazione di qualche tipo e si riferiscono ad essi come "Entità". Entity è il nome effettivo della classe ed è la classe predominante da utilizzare per animare qualcosa come un personaggio che si muove sullo schermo.

C'è un po 'di convenzione in questo momento in cui ti riferisci a cose come barriere, nemici, personaggi, ecc. come "entità". Detto questo, se stai usando FlashPunk per la tua grafica, è sbagliato creare una classe base per rappresentare tali cose e nominarla anche Entity ? (In particolare, questo viola una convenzione di codifica ampiamente condivisa?)

Ovviamente sarebbe in un pacchetto diverso, e la maggior parte delle persone probabilmente separerebbe la grafica dallo stato attuale del gioco, quindi non c'è molta sovrapposizione lì. Sta usando solo lo stesso titolo.

Che dire di scenari come questo in generale con la programmazione? Esiste una convenzione particolare?

    
posta Panzercrisis 24.06.2014 - 02:46
fonte

3 risposte

2

Il problema principale che vedo con questo è che parlando del tuo codice otterrai un sacco di "quale entità intendi?" domande.

La maggior parte dei linguaggi informatici moderni (e molti di quelli più vecchi) forniscono il nome scoping per evitare questo problema, ma l'inglese è più vecchio di tutti e ha solo un debole accenno al contesto. Il che significa che se segui questa strada aggiungerai molte qualifiche alle tue discussioni per disambiguare l'ambiguità che hai aggiunto.

Molto meglio sarebbe chiamare qualcos'altro come "discendente di root" o classe di wrapper. Sprite è probabilmente un buon nome.

    
risposta data 24.06.2014 - 06:22
fonte
2

Questo problema è stato essenzialmente risolto decenni fa.

Se la tua lingua lo consente, tieni semplicemente l'API di terze parti e il tuo codice in spazi dei nomi separati (pacchetti in Ada, spazi dei nomi in C ++, moduli in Modula-2 ecc.).

Dove non è ovvio quale Entità stai usando, fai riferimento a tutte le Entità che usano nomi qualificati, ad es. FlashPunk.Entity o MyApp.Entity (Ada) o MyApp::entity (C ++)

Dove ti stai riferendo quasi esclusivamente a uno spazio dei nomi, diventa troppo prolisso. Quindi puoi use MyApp (Ada) o using namespace MyApp (C ++) per rendere questo spazio dei nomi disponibile nell'ambito corrente, quindi devi solo qualificare solo i nomi dell'altro spazio dei nomi.

Può a volte aiutare la chiarezza a qualificare alcuni dei nomi dallo spazio dei nomi use d, ad es. quando le entità di entrambi gli spazi dei nomi sono utilizzate nella stessa istruzione, o qualsiasi stranezza del loro uso potrebbe confondere il lettore.

    
risposta data 24.06.2014 - 15:27
fonte
1

Quando si utilizzano librerie di terze parti, è probabile che si verifichi una collisione di nomi perché denominare gli oggetti non è una cosa facile da fare e non ci sono molti nomi eleganti che si possono assegnare agli oggetti per dare loro un significato rappresentativo. Detto questo, se non avrai molte di queste collisioni che causerebbero molta confusione a chiunque legga / usi il tuo codice, usa gli stessi nomi. Il mio suggerimento è di evitare di nominare le collisioni il più possibile.

Per il tuo particolare esempio, invece di usare il nome Entity , potresti usare EntityBase .

    
risposta data 24.06.2014 - 03:00
fonte

Leggi altre domande sui tag

E 'una cattiva forma usare le caratteristiche di C come il tipo size_t invece delle loro controparti c ++, come std :: size_t? Come ti avvicineresti alla notifica degli errori?