Scrivere un codice procedurale pulito ed elegante (base): esiste una cosa del genere?

Question

Ho imparato a codificare in lingue OO. Sono sempre stato interessato a schemi di progettazione, codice pulito, ecc. Ecc. - Conosci il tipo.

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

Sto riflettendo sui seguenti problemi e mi chiedo se sono sulla linea giusta.

---

Nomi variabili

Le variabili non sono fortemente digitate (incubo!), Vengono dati nomi corti e scritti in tutti i tappi (perché?!) - Fondamentalmente le trovo difficili da leggere e potrebbero essere qualsiasi cosa. C'era una volta, ne sono sicuro XCNT = 1 avrebbe offerto guadagni di performance int_EXISTINGCUSTOMERCOUNT = 1, ma ora lo abbiamo superato - sicuramente? Scelgo qui il nome verboso.

Gosub

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

Questo è tipico:

GOSUB GET_BEST_CUSTOMER
IF RC = 0 THEN CRT CNAME

Ma scrivo:

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 modificherebbe solo rc_GETBESTCUSTOMER e str_CUSTOMERNAME nell'ambito "globale".

---

C'è di più, ma è lungo le stesse linee. Dato l'editore di scelta (blocco note ++), 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 mobili di base mi direbbero prontamente che sto sbagliando tutto.