Lettere maiuscole per i modelli con nome

Question

In Mathematica I simboli incorporati iniziano con lettere maiuscole. Pertanto è prassi comune non iniziare i nomi dei simboli creati dall'utente con lettere maiuscole.

Quanto deve essere estesa questa limitazione ad altri aspetti della sintassi? Le buone pratiche richiedono che una lettera maiuscola non venga utilizzata per un modello denominato in un'espressione SetDelayed o RuleDelayed (dove tali nomi sono localizzati)?

Penso che le maiuscole espandano il namespace in un modo utile e visualizzano visivamente le lettere minuscole L e 1, ad esempio. Consentono inoltre che gli argomenti vengano nominati in maniera da manuale.

Se vengono introdotti nuovi simboli nelle versioni future, i patter denominati devono sostituirli e il codice esistente non deve interrompersi.

Un cono è ambiguità se vengono utilizzati nomi esistenti come N e D, ma ritengo che sia il contesto di utilizzo sia l'evidenziazione della sintassi FrontEnd lo attenuino.

Answer 1

Questa è una pratica accettata che non accetto!

Mi riferisco a pacchetti, per uso personale o di terze parti. In generale, voglio che il mio lavoro finito sia il più possibile indistinguibile dall'aspetto, dall'aspetto e dalla qualità ideali (WRI). Include nomi descrittivi lunghi per i miei comandi, con tutte le convenzioni di maiuscole utilizzate da WRI.

Naturalmente i miei pacchetti sono - al momento - tutt'altro che vicino alla qualità WRI, ma almeno sto cercando di integrarli nel miglior modo possibile con la funzionalità MMA standard. E questo include avere comandi in maiuscolo.

Durante lo sviluppo, l'evidenziazione della sintassi mi avvisa di possibili conflitti con le funzioni MMA standard, pertanto è possibile intraprendere azioni appropriate. Naturalmente i miei comandi e pacchetti potrebbero entrare in conflitto con le versioni future di MMA, ma nulla dura per sempre e se un futuro comando MMA è simile nel nome e nella funzionalità a uno dei miei, passerò semplicemente alla funzione standard con modifiche minime o nulle denominazione.

Oltre a ciò, trovo molto più attraente l'uso visuale di lettere maiuscole per distinguere i comandi del pacchetto da variabili temporanee più modeste. Se vuoi vedere qualche codice visivamente opaco/sgradevole, guarda solo un codice Maple medio.

Riguardo alle variabili di pattern, cerco di dare nomi di pattern significativi, per lo più brevi, senza maiuscole, quindi l'utente può indovinare guardando il modello Ctrl/Cmd-K che tipo di input è previsto nei miei comandi del pacchetto.