Scrivere un codice procedurale pulito ed elegante (BASIC): Esiste una cosa del genere?

Question

Scrivere un codice procedurale pulito ed elegante (BASIC): Esiste una cosa del genere?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Ho imparato a codificare nelle lingue OO. Sono sempre stato interessato a modelli di design, codice pulito, ecc. Ecc., Conosci il tipo.

Ora al lavoro sto usando un dialetto BASIC. Dati i moderni valori di programmazione, dovremmo provare a trasferire questi stessi principi su un nuovo codice procedurale?

Sto meditando sui seguenti problemi, e mi chiedo se sono sulla buona strada.

Nomi di variabili

Le variabili non sono strongmente tipizzate (incubo!), hanno nomi brevi e sono scritte in MAIUSCOLO (perché ?!) - fondamentalmente le trovo difficili da leggere e potrebbero essere qualsiasi cosa . C'era una volta, sono sicuro che XCNT = 1 avrebbe offerto guadagni in termini di prestazioni superiori a int_EXISTINGCUSTOMERCOUNT = 1 , ma ora lo superiamo - sicuramente? Scelgo qui il nome dettagliato.

GOSUB

Voglio abbattere lunghi blocchi di codice in più blocchi più piccoli. Internamente, viene utilizzato GOSUB (oltre un FUNCTION ) se l'helper non è riutilizzabile da altri programmi / funzioni. Data la sua capacità di aggiungere / modificare variabili senza la sicurezza dell'ambito (come lo conosciamo nel mondo OO) GOSUB mi spaventa.

Questo è tipico:

GOSUB GET_BEST_CUSTOMER
IF RC = 0 THEN CRT CNAME

Ma scriverei:

rc_GETBESTCUSTOMER = 1 ; !Default exception
str_CUSTOMERNAME = ""
GOSUB GET_BEST_CUSTOMER ; !set rc_GETBESTCUSTOMER, populate str_CUSTOMERNAME
IF(rc_GETBESTCUSTOMER = 0) THEN
    CRT str_CUSTOMERNAME
END

Con l'avvertenza che GET_BEST_CUSTOMER modificerebbe solo rc_GETBESTCUSTOMER e str_CUSTOMERNAME in ambito "globale".

C'è di più, ma è tutto sulla stessa linea. Dato l'editor di scelta (Notepad ++), direi che il mio stile di codifica semplifica la lettura e la comprensione del codice, quindi è più facile da mantenere. Ma sono sicuro che alcuni BASIC duri a morire mi direbbero che sto sbagliando tutto.

clean-code programming-practices procedural naming-standards basic

posta Tom Tom 19.02.2013 - 10:50

fonte

3 risposte

2

Nomi di variabili

Non si trattava di prestazioni, ma del sistema di essere in grado di interpretare valori con una lunghezza di carattere inferiore a qualche valore (8 nella maggior parte dei casi). Sì, i nomi delle variabili prolissi sono ora consentiti ovunque e li usano per il contenuto del tuo cuore, ma se ottieni codice legacy non cambierai i nomi delle variabili solo perché non ti piace (come per ogni buona pratica di codifica dovrebbe dirlo comunque). Inoltre, tutte le protezioni sono state utilizzate poiché alcuni sistemi potrebbero non essere necessariamente sullo standard ASCII, né alcuni sistemi avrebbero prodotto lo stesso stile di stampa sullo schermo, i cappucci sono un modo semplice per risolverli poiché dovrebbero essere quasi em> simile.

GoSub

Se non puoi proteggere con l'ambito, proteggi con i nomi. Ogni nome di subroutine dovrebbe essere breve, in questo modo se ci si deve preoccupare delle variabili di "scoping", è possibile aggiungere il nome della subroutine alla parte anteriore o posteriore della variabile, gestire il descrittivo della subroutine nei commenti, non il nome.

Onestamente, non c'è un importante cambio di paradigma da OOP a Procedural, sì ci sono alcuni problemi semantici, ma le subroutine sono fondamentali per mantenere il codice gestibile e semi-modulare, proprio come le classi e i metodi sono lì per lo stesso scopo in OOP .

E, come sempre, stai lontano da GOTO (Dijkstra).

risposta data 19.02.2013 - 14:54
fonte

0

Il manuale di riferimento di UniBASIC 9.3 indica un limite di 32 caratteri per i nomi delle variabili. Iff l'opzione LONGVARS è attiva, altrimenti è max due caratteri per nome di variabile.

I nomi non fanno distinzione tra maiuscole e minuscole. Foo , FOO , foo , fOo , ... sono tutti lo stesso nome. Usare tutte le maiuscole è una tradizione dai tempi in cui esistevano macchine / sistemi che avevano solo un caso per i caratteri e che di solito era maiuscolo.

Che cosa intendi per variabili che non vengono strongmente digitate? Sono o un numero o una stringa quando il nome termina con $ .

Non ho trovato una parola chiave FUNCTION nella documentazione così GOSUB è il modo di scrivere subroutine. Poi c'è CALL e ENTER per i sottoprogrammi. L'unico modo per definire le funzioni è DEF FN che limita i nomi delle funzioni a una lettera e l'implementazione a un'espressione one .

Assegnare un nome al valore di ritorno dopo che il nome della subroutine sta sprecando variabili. Sì, il numero di variabili per programma ha anche un limite. Il valore predefinito è 348 nomi, ma questo può essere aumentato tramite la variabile di ambiente MAXVARS. La documentazione suggerisce che il valore predefinito era inferiore a 93 in passato.

risposta data 12.07.2018 - 17:35
fonte

Leggi altre domande sui tag clean-code programming-practices procedural naming-standards basic

Come trovare una buona pagina iniziale per un web crawler? [chiuso] npm packages.json: devDependencies vs installazione globale

score 1 · Accepted Answer

GOSUB

GOSUB era una versione più disciplinata di GOTO. Questo è un esempio particolarmente orribile del tipo di abuso di GOTO che un tempo era popolare. GOSUB è un enorme passo avanti e sembra che la tua base di codice stia usando le etichette invece dei numeri di linea per gli obiettivi GOSUB, quindi potrebbe davvero essere molto peggio.

Non so quale dialetto di BASIC stai usando, e non ho mai usato FUNCTION nel piccolo programma BASIC che ho fatto molto tempo fa, ma se FUNCTION nel tuo dialetto di BASIC è qualcosa di simile a una chiamata di funzione di lingua moderna, preferirei su GOSUB per il nuovo codice. Nel codice di esempio, la sostituzione proposta era 3 volte più lunga dell'originale a 2 righe, quindi non posso davvero essere d'accordo sul fatto che sia più leggibile, ma suppongo che una riscrittura dell'originale usando FUNCTION finirà per avere circa lo stesso lunghezza e chiarezza dell'originale.

Naming

Non vedo il punto nel collegare il tipo alla parte anteriore del nome della variabile. I tuoi nomi lunghi sono un miglioramento rispetto a XCNT , ma EXISTING_CUSTOMER_COUNT è più leggibile (IMO) che eseguirli insieme e incollare un prefisso di tipo su di esso. Potresti eseguirli insieme a causa del fatto che sei abituato a CamelCase, ma non puoi fare il caso del cammello in maiuscolo.