I sigilli facilitano la lettura del codice sorgente?

Le possibilità e le limitazioni tecniche attuali non sono nulla del tipo suggerito in questa discussione. Scacciamo i primi.

Ecco cosa $ rende possibile in PHP:

• Variabili variabili
• Variabili con nome di parola chiave, ad es. $return o essere in grado di usare lo stesso nome per una variabile e un functon / costante per es. %codice%

Limitazioni o funzioni non correlate al prefisso $:

• L'implementazione altrimenti non è in grado di distinguere tra funzioni e variabili
• Interpolazione di stringa PHP o sintassi del modello
• Dichiarazione di variabili richieste

Ciò significa che non esiste un motivo tecnico che non potresti avere

foo = "something";
echo foo;

o

foo = "something";
echo "foo = $foo";
//would print
//foo = something 

Tuttavia non puoi avere (supponendo che $__FILE__ sia una parola chiave)

return = "something";

Senza gravi complicazioni. Se hai usato un prefisso come return , allora non lo farebbe ho avuto qualche problema.

È un'opinione, ma credo che un sigillo varrebbe la pena per i non programmatori poiché consente loro di usare parole chiave come nomi di variabili, a loro sembrerebbe altrimenti una limitazione arbitraria: P

I sigilli in realtà hanno molto più senso in perl, dove forniscono una certa quantità di controllo del tipo. In PHP non aiutano molto al di fuori dei modelli. Puoi avere un'idea della loro utilità e leggibilità guardando in diverse lingue. Quasi nessuno li usa.

In un linguaggio mirato all'utente finale su cui sto lavorando, vado anche oltre, rendendo gli identificatori case insensibili e consentendo spazi e apostrofi. Ciò mi consente di creare nomi di variabili come Karl's height più vicini ai linguaggi naturali.

Anni fa, ho appreso Applesoft Basic. Le stringhe erano sempre suffisse con $ e gli array avevano un suffisso di % . Ecco come funzionava la lingua. Hai guardato qualcosa, sapevi cosa fosse. Non ho mai approfondito troppo l'interprete per capire perché questo è il caso o le decisioni di progettazione che lo hanno reso così.

Il sigillo in php deriva dalla sua influenza perl (che è stata influenzata da awk e sh ). Il sigillo in perl è un po 'più di solo $ in quanto può identificare molti tipi diversi:

• $ scalare
• @ list
• % hash
• & codeblock
• * typeglob

Il sigillo identifica quale parte della struttura della tabella dei simboli si sta guardando. Dietro le quinte, la voce della tabella dei simboli per foo (accessibile tramite *foo - typeglob) ha tutto ciò che può essere un foo. C'è $foo , @foo , %foo , il formato foo , &foo , il filehandle pippo, ecc ...

Ciò consente anche di creare un alias di una variabile in un'altra:

#!/usr/bin/perl

$foo = "foo";
@qux = (1,2);
*bar = \$foo;
*bar = \@qux;

print "$bar @bar\n";

Questo stampa foo 1 2 - in perl, questo è ciò che i sigilli sono veramente per, non che dovresti farlo, ma piuttosto che c'è questa cosa dietro le quinte che fanno.

I sigilli non ci sono tanto per la leggibilità, ma piuttosto per poter avere $foo e @foo senza avere una collisione nello spazio dei nomi (confrontare altre lingue dove non è possibile avere entrambi int foo; int[] foo; )

I sigilli per la leggibilità sono qualcosa che viene appreso come parte di qualsiasi lingua - leggendo la sintassi. Potresti, ipoteticamente, applicare il tipo stesso (come notazione ungherese) per far parte dell'identificatore.

Qualcosa in Lex lungo le linee di:

typeChar  [is]
capLetter [A-Z]
letter    [a-z]
digit     [0-9]
%%
{typeChar}{capLetter}(letter}|{digit})* { prientif("iddentifier");}
%%

E quindi potresti avere un codice come

iFoo = 42;
sFoo = "a string";
iBar = iFoo * 2;

Non sto dicendo che sia una buona idea, ma piuttosto che qualcuno che è abituato alla lingua sarà in grado di leggerlo in modo nativo e pensare che migliori la leggibilità mentre qualcuno che non ha familiarità con la lingua potrebbe pensare che aggiunge solo un po 'di rumore alla lingua.

Tuttavia, dopo aver lavorato con un linguaggio definito in questo modo, probabilmente potrei leggerlo senza problemi.

Alcune persone come loro, alcune persone no. Ci sono grandi guerre sante in vari forum di discussione su questo e si riduce davvero a quanto le hai usate.

Si potrebbe progettare un nuovo linguaggio per i non programmatori che usano sigilli e chiunque non abbia mai programmato prima non si lamenterà mai di loro. D'altra parte, non è possibile averli come parte della lingua e quindi i programmatori di ruby o perl si lamentano di perdere alcune informazioni chiave.

In realtà non importa. Ciò che importa è come i sigilli si adattano al linguaggio se li usi o meno. Vuoi essere in grado di fare "123 $foo 456" o devi fare "123 " + foo + " 456" ? Questo è dove la decisione dovrebbe essere presa.

Non sono d'accordo che PHP usi $ per differenziare vars da funcs. Almeno perché PHP ha una sintassi simile a C, e funcs () hanno parentesi dopo il nome.

Leggi questo post su overflow dello stack sul perché $ è in PHP.

Molti linguaggi popolari, come C, C ++, C #, Java non usano $ e possiamo distinguere facilmente var dalla funzione.

In PHP $ aiuta, per esempio, quando scrivi:   echo "var = $ var"

Senza $ un simile trucco sarà impossibile.

Dopo tutte queste risposte, voglio dare qualche altro punto a Mathew Foscarini.

• Considerate il problema ora come un "costruttore di linguaggio". Prova a capire perché un'altra lingua ha questa o quella caratteristica per scegliere se utilizzare qualcosa nella tua lingua. Sono nella stessa posizione da molti anni, perché sviluppo parser SQL per il nostro database Valentina.
• Consiglio di dare un'occhiata a antlr.org e di leggere anche il libro di Terence. Ha un sacco di cose carine per gli sviluppatori di lingue.
• Non sono ancora d'accordo con "ragioni" esposte da altre risposte. Assumono che l'autore in testa di PHP abbia deciso di usare $ per poter usare parole chiave riservate e meglio distinguere le variabili da non variabili. Io non la penso così ... anche se la prova può essere solo la sua / la propria storia.
• Molto probabilmente si limitano a seguire perl e altre lingue antiche. Come sottolinea Terrence, la maggior parte delle lingue sono simili, specialmente nella parte LEXER. E di solito il costruttore di una nuova lingua può semplicemente scegliere quale tipo di linguaggio svilupperà e quindi prendere in prestito quella grammatica linguistica. E questo è quello che dovresti fare ora. Non c'è bisogno di inventare da zero. E scommetto che lo stesso ha fatto gli autori di PHP.
• Tutto il resto di ciò che la gente menziona:
  • distinguere le variabili da non variabili
  • parole riservate come nomi di variabili
  • possibilità di inserire variabili all'interno della stringa
  • potrebbe essere altrimenti (non sono un grande esperto in PHP)

sono effetti collaterali di questo LEXER , perché è in grado di riconoscere un token.

Prendi come esempio: in SQL usiamo "" per essere in grado di utilizzare identificatori con parole riservate e persino identificatori con spazi "Nome", "Nome gruppo". GROUP è una parola chiave. C'era un problema: c'era una soluzione speciale.

P.S. Ottimo commento da parte di MichaelT.

... un sigillo consente di:

• Meglio distinguere le variabili da non variabili . Le persone che stanno ancora imparando concetti di base potrebbero avere difficoltà a capire quali parole sono variabili e quali no. Spesso iniziano leggendo esempi o codice di altre persone senza uno sfondo adeguato.

• Utilizza parole chiave riservate o nomi di funzioni come nomi di variabili . A volte ho trovato alcuni di quei nomi come quelli giusti per una variabile (cioè $count mentre era definita una funzione count() ) e ho ringraziato i sigilli per avermi permesso di usarli.

Also I happen to do that function name reusing frequently, for holding a function's result in a throwaway variable, e.g.:

$isdir=isdir($dir);

if(/* complex condition implying $isdir */) {
/* etc */
}