Segnaposto nelle stringhe

Question

Segnaposto nelle stringhe

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

7

Trovo che a volte utilizzi segnaposti nelle stringhe, come questo:

$ cat example-apache
<VirtualHost *:80>
    ServerName ##DOMAIN_NAME##
    ServerAlias www.##DOMAIN_NAME##
    DocumentRoot /var/www/##DOMAIN_NAME##/public_html
</VirtualHost>

Ora sono sicuro che si tratti di un problema minore se il segnaposto è ##DOMAIN_NAME## , !!DOMAIN_NAME!! , {{DOMAIN_NAME}} o qualche altra variante. Tuttavia, ora ho bisogno di standardizzarmi con altri sviluppatori su un progetto, e tutti abbiamo interesse a far sì che il nostro formato di segnaposto sia reso standard nell'organizzazione. Ci sono dei buoni motivi per scegliere uno di questi o altri? Sto cercando di quantificare queste considerazioni:

Estetica e usabilità . Ad esempio, __dict__ può essere difficile da leggere in quanto non sappiamo quanti caratteri di sottolineatura ci sono.
Compatibilità . Qualche lingua cercherà di fare qualcosa di divertente con la sintassi {} in una stringa (come PHP fa con "Welcome to {$siteName} today!" )? In realtà, so che PHP e Python non lo faranno, ma altri? Un preprocessore C ++ subirà un choke sul formato ## ? Se ho bisogno di memorizzare il valore in qualche motore SQL, non considererà qualcosa un commento? Qualche altra insidie di cui diffidare?
Maintainability . Il nuovo tipo scambierà ##SOME_PLACEHOLDER## come costrutto linguistico?
Lo sconosciuto . Sicuramente il saggio qui penserà ad altri aspetti di questa decisione a cui non ho pensato.

Potrei essere bikehedding questo, ma se ci sono problemi reali che potrebbero essere in agguato, mi piacerebbe sicuramente per conoscerli prima di imporre che i nostri sviluppatori aderiscano a una convenzione potenzialmente problematica.

coding-style

posta dotancohen 27.06.2013 - 17:55

fonte

3 risposte

3

Dai un'occhiata ad alcuni progetti che ammiri e segui la loro convenzione.

Non inventare qualcosa di nuovo, prova a scoprire cos'è una convenzione tipica e ad utilizzarla.

Assicurati di includere un modo per sfuggire alla sequenza di caratteri in modo da poterlo includere come letterale senza che venga interpretato come un token.

risposta data 27.06.2013 - 17:57

fonte

2

Nelle settimane trascorse da quando ho fatto questa domanda, ho imparato quali caratteri evitare . Li elenco qui per il mio uso personale e per gli altri:

Evita * e _ mentre alcuni software di tracciamento dei problemi (come redmine ) li usano per la sintassi wiki e sostituiranno i valori nei rapporti sui bug copiati.
Bash assolutamente soffoca su ! , in effetti non puoi nemmeno risalire la freccia indietro per ripristinare la linea.

risposta data 18.08.2013 - 12:24

fonte

Leggi altre domande sui tag coding-style

Puoi esagerare con i delegati e gli eventi Odiando il tuo codice - nel bene o nel male, come lo gestisci? [chiuso]

score 9 · Accepted Answer

Uso personalmente segnaposti e nel corso degli anni ho sedimentato le seguenti considerazioni, in ordine di priorità:

Assolutamente nessun metacarattero della shell, perché uso spesso degli script. Evita: $ < > () {} |
nessuna sequenza di escape: \
nessun carattere regexp-rischioso, la ricerca che potrebbe essere un incubo di fuga:. - *? '"
nessun operatore matematico e comune: + - / *

Questo lascia pochi candidati:%: ^ # _ @ (dove ^ e% sono spesso operatori e dovrebbero essere esclusi).

Personalmente , io uso gli ultimi tre - # _ @

I costrutti linguistici probabilmente porteranno a rifuggire%, @ e ^ (anche se @@@ DOMAIN_NAME @@@ è un bel calcio nei denti: non puoi perderlo)

Usando caratteri a lunghezza fissa, uso indifferentemente _ e #. Forse sono più incline a __THIS_FORM__ che è addirittura legale in C (pericolo Will Robinson! Potresti avere delle costanti C formattate in quel modo!).

Penso che # sia una scelta migliore se hai problemi di leggibilità. ###DOMAIN_NAME### sembra abbastanza buono ed è improbabile che arrivi in qualsiasi lingua che conosca. E ###_DOMAIN_NAME_### è più complicato, ma forse più leggibile.

Ovviamente in alcuni domini specifici potresti effettivamente voler scimperare alcuni schemi esistenti (es. usare i metacaratteri della shell), sia per rendere più chiaro che quelle stringhe sono realmente segnaposto, o perché puoi sfruttare ( con la dovuta cura) alcuni strumenti per ampliarli: quindi ad es {{ varname }} , ${ varname } , $(varname) o [[ varname ]] .

In script come VirtualHost, tendo a usare @@@NAMES@@@ ... forse non avrei dovuto tentare di rispondere, dal momento che non sono in grado di concordare uno standard anche con me stesso!