In most programming languages, variables do not have identifying characters like they do in PHP. In PHP you must prefix a variable with the $ character.


 var $foo = "something";
 echo $foo;

I'm developing a new scripting language for a business application, and my target users do not have a programming background. Do these characters make code easier to read and use?

One reason PHP uses the $ is because without it PHP can't tell if a name is a function reference or variable reference. This is because the language allows strange references to functions. So the $ symbol helps the parser separate the namespace.

I don't have this problem in my parser. So my question is purely on readability and ease of use. I have coded for so many years in PHP that when I see $foo it's easy for me to identify this as a variable. Am I just giving a bias preference to this identifier?

  • 19
    IMO, code is more readable without sigils Commented Aug 17, 2013 at 11:46
  • 6
    @JanDvorak +1 for giving a me new word of the day. I shall try to use sigils three times today in conversations.
    – Reactgular
    Commented Aug 17, 2013 at 11:47
  • 6
    IMO It depends if your editor has syntax highlighting.
    – CodeBeard
    Commented Aug 17, 2013 at 11:53
  • 5
    If you use var $x = ... or type $x = ... then I think $ is overkill. If you just had $x = ... then it could be worth doing. Especially if you don't want to support syntax highlighting in common editors. However, as a preference, I don't like sigils
    – CodeBeard
    Commented Aug 17, 2013 at 11:59
  • 5
    sigils are like a enforced hungarian notation Commented Aug 17, 2013 at 19:22

6 Answers 6


The actual technical possibilites and limitations are nothing of the sort as are suggested throughout this thread. Let's clear out those first.

Here's what $ is making possible in PHP:

  • Variable variables
  • Variables with keyword name e.g. $return or being able to use same name for a variable and a functon/constant e.g. $__FILE__

Limitations or features that are unrelated to the $ prefix:

  • The implementation otherwise being unable to tell difference between functions and variables
  • PHP string interpolation or template syntax
  • Required variable declaration

That means there is no technical reason you couldn't have

foo = "something";
echo foo;


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

However you cannot have (assuming return is a keyword)

return = "something";

Without serious complications. If you used a prefix like $, then it would not have been any problem.

It's an opinion but I believe a sigil would be worth it for non programmers since it enables them to use keywords as variable names, to them it would otherwise look like arbitrary limitation :P

  • About return = "something";, C# has "contextual keywords", which is also an option worth checking out when designing languages.
    – luiscubal
    Commented Aug 20, 2013 at 17:22
  • 1
    @luiscubal writing that in C# non-surprisingly requires a sigil, so if you want that code to be compiled, you need to write @return = "something;". There is some amount of contextual keywords, yes, but making all of them contextual would mean much more complicated implementation.
    – Esailija
    Commented Aug 20, 2013 at 17:53

Sigils actually make a lot more sense in perl, where they provide a certain amount of type checking. In php they don't help much outside of templating. You can get a sense of their usefulness and readability by looking around at different languages. Hardly any use them.

In an end user targeted language I'm working on, I even go further, making identifiers case insensitive and allowing spaces and apostrophes. That lets me make variable names like Karl's height that are much closer to natural languages.

  • 1
    +1 for spaces in variables, but I have no idea how to implement that. Not sure I'd find that easier to read either. I'm just not use to it.
    – Reactgular
    Commented Aug 17, 2013 at 13:36
  • 1
    I like the idea. But I would hate to write the parser for a language with space's in the identifier. :-) At Karl's for the night = true; Commented Aug 17, 2013 at 16:24
  • But it would be interesting to see all these standards that we add to the top of a language to help us read it. Rather than be manually checked by an external tool but become part of the language definition. That way we can't have pointless arguments about identifier names in the coding standards (as they are in the language). Commented Aug 17, 2013 at 16:27
  • 2
    Case insensitivity has the problem of internationalization, though. If you allow characters from many languages, you may run into names that are "the same" in some locales, but not in others.
    – luiscubal
    Commented Aug 18, 2013 at 16:05
  • 1
    Allowing whitespace in variables isn't a big deal in principle - it just means a grammar rule for identifiers that allows multiple words. However, it does mean other things may not be possible in the grammar without creating ambiguity. For example, in Haskell, map sum is a partially-applied function call - the function sum is passed as a parameter to map. But both of those are just library names, so with multi-word identifiers, the compiler couldn't know if map sum is one multi-word identifier or a function application based on two single-word identifiers.
    – user8709
    Commented Aug 31, 2013 at 2:20

Years ago, I learned Applesoft Basic. Strings were always suffixed with $ and arrays had a suffix of %. Thats just how the language worked. You looked at something, you knew what it was. I never did delve too far into the interpreter to understand why this was the case or the design decisions that made it so.

The sigil in php comes from its perl influence (which was influenced by awk and sh). The sigil in perl is quite a bit more than just $ as it can identify many different types:

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

The sigil identifies what part of the symbol table structure you are looking at. Behind the scenes, the symbol table entry for foo (accessed via *foo - the typeglob) has everything that may be a foo. There is $foo, @foo, %foo, the format foo, &foo, the filehandle foo, etc...

This also allows making an alias of one variable to another:


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

print "$bar @bar\n";

This prints foo 1 2 - in perl, this is what the sigils are really for, not that you should do this but rather that there is this behind the scenes thing that they do.

The sigils aren't there so much for readability, but rather so that one can have $foo and @foo without having a collision in the namespace (compare other languages where one cannot have both int foo; int[] foo;)

Sigils for readability are something that is learned as part of any language - reading the syntax. You could, hypothetically, enforce the type itself (as hungarian notation) to be part of the identifier.

Something in lex along the lines of:

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

And then you could have code like

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

I'm not saying this is a good idea, but rather that someone who is accustom to the language will be able to read this natively and think that it enhances readability while someone who isn't familiar with the language may think that it just adds a bunch of noise to the language.

However, after working with a language defined this way, I could probably read it without trouble.

Some people like them, some people don't. There are great holy wars in various forums debating this and it really boils down to how much you've used them.

One could design a new language for non-programmers that uses sigils and anyone who has never programed before will never complain one bit about them. On the other hand, you could not have them as part of the language and then have ruby or perl programers complain that they're missing out on some key information.

It really doesn't matter. What does matter is how sigils would fit into the language if you use them or not. Do you want to be able to do "123 $foo 456" or must you do "123 " + foo + " 456"? This is where the decision should be made.

  • 1
    String interpolation such as "123 $foo 456" is not enabled by the sigil prefix and is completely orthogonal to it.
    – Esailija
    Commented Aug 18, 2013 at 0:32
  • 1
    Its part of interpolation of variables and depends on how one parses a string. Sigils can make that easier (it can be done other ways as shown by Best way to do variable interpolation in javascript? but that isn't part of the core language. Sigils, arguably, make it much easier to write and understand this.
    – user40980
    Commented Aug 18, 2013 at 0:39
  • 1
    @MichaelT No, the fact that variables have prefixes do not make implementing string interpolation easier or harder. They are just 2 completely unrelated things. To a human reader, it might have been good choice to use $asd in the string interpolation syntax if $ was already used for variable prefixes, but it had nothing to do with actual possiblity of implementing string interpolation in the first place.
    – Esailija
    Commented Aug 18, 2013 at 0:42
  • 2
    @Esailija could you describe how they are unrelated? As an aside, from en.wikipedia.org/wiki/Variable_interpolation - "Languages that support variable interpolation include Perl, PHP, Ruby, Tcl, Groovy, and most Unix shells. In these languages, variable interpolation only occurs when the string literal is double-quoted, but not when it is single-quoted. The variables are recognized because variables start with a sigil (typically "$") in these languages."
    – user40980
    Commented Aug 18, 2013 at 0:45
  • @MichaelT The dollar symbol being used in variable prefixes and string interpolation is completely superficial choice (which has only readability arguments, not anything to do with implementing, it might as well be # which is used in coffeescript for example. And coffeescript doesn't prefix variables with #- in fact it doesn't prefix variables at all)
    – Esailija
    Commented Aug 18, 2013 at 0:46

I not agree that PHP uses $ to differ vars from funcs. At least because PHP have C-like syntax, and funcs() have parens after the name.

Read this post on stack overflow about why $ is in PHP.

Many popular languages, such as C, C++, C#, Java do not use $ and we can differ easy var from function.

In PHP $ helps, for example, when you write: echo "var = $var"

Without $ such trick will be impossible.

  • +1 ah that does make more sense. Thanks.
    – Reactgular
    Commented Aug 17, 2013 at 13:37
  • 3
    A language having sigils has nothing to do with it having string interpolation as in your example of echo "var = $var"
    – user7007
    Commented Aug 17, 2013 at 14:39
  • 4
    -1. PHP syntax quirks are not because of some actual limitation but because the grammar rules are extremely poorly designed, if designed at all. This is why they need hacks to enable fn()[] where as with sensible grammar that would have worked out of the box without even thinking about it.
    – Esailija
    Commented Aug 17, 2013 at 15:02
  • @svidgen Yes. You cannot safely do string interpolation without some way to indicate what part of the string is supposed to map to a variable. Other languages end up with what I consider to be annoying/unnecessary verbosity, like Python's string formatting. However, there are other advantages as well in PHP: RuslanZasukhin is incorrect in saying that functions will always be indicated with parens, as they can also be passed around as references.
    – Izkata
    Commented Aug 17, 2013 at 15:14
  • @Izkata The way you use variables in a language has nothing to do with string interpolation syntax. But that was implied in this answer, hence -1...
    – Esailija
    Commented Aug 17, 2013 at 15:19

After all this answers, I want give some more points to Mathew Foscarini.

  • You consider problem now as a "language constructor". You try understand why another language have this or that feature to choose if to use something in your own language. I am in same position many years, because developing SQL parser for our Valentina Database.
  • I advice you take a look on antlr.org and even read book from Terence. It has a lots nice things for language developers.
  • I still not agree to "reasons" exposed by other answers. They assume that PHP author in head have decide to use $ to be able use reserved keywords and Better distinguish variables from non-variables. I do not think so ... although prove can be only his/their own story.
  • Most probably that they just follow to perl and more early languages. As underlines Terrence, most languages are similar, especially in LEXER part. And usually constructor of a new language can just choose what kind of language he is going to develop and then take lexer of that language grammar. And this is what you should do now. No need invent from scratch. And I bet the same did PHP authors.
  • All else what people mention:
    • distinguish variables from non-variables
    • reserver words as variable names
    • ability to place variable inside of string
    • may be else (I am not big expert in PHP)

are side-effects of this LEXER, because it is able to recognize a token.

Take as example: in SQL we use "" to be able to use identifiers with reserved words and even identifiers with spaces "First Name", "Group Name". GROUP is a keyword. There was problem - there was special solution.

P.S. Very good comment from MichaelT.

  • +1 thanks for the great link. I ended up using this one, but your link looks a lot better. goldparser.org
    – Reactgular
    Commented Aug 18, 2013 at 9:40
  • Thank you also for your link. I have not see this gold parser one before. Looks also interesting. Commented Aug 18, 2013 at 11:13
  • @RuslanZasukhin if you are making a reference to my answer, I never said it was developer's intention to enable keywords. I only said that using keywords as variables names becomes technically possible when variables are prefixed with a symbol like $. Also the "ability to place variable inside string" is not because of variables being prefixed with a symbol like $. That is, "123 $foo 456" will work if even if variable syntax is like foo = 3 or @foo = 3. They are not related to each other.
    – Esailija
    Commented Aug 18, 2013 at 11:21

...a sigil allows to:

  • Better distinguish variables from non-variables. People that are still learning basic concepts might have trouble figuring out which words are variables and which don't. They often start by reading examples or other people's code with no adequate background.

  • Use reserved keywords or function names as variable names. At times I found some of those names to be the right ones for a variable (i.e. $count while there was a count() function defined) and thanked sigils for allowing me to use them.

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


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

  • 1
    ZHR, what means better? In C++ we write all our variables without $ and we perfectly and easy distinguish them. Example: { int z = 0; z = 55; z(z); } And in C++ we also can use function name if need to assign, for example pointer to function. Commented Aug 18, 2013 at 7:16
  • @RuslanZasukhin, Computer illiterates, do you know some? Try teaching them C++, you'll be amazed.
    – ZJR
    Commented Aug 18, 2013 at 11:42
  • Also: I don't think a sigil must always be a $ sign. I remember the dollar sign confusing me when I was a kid because of its inherent money association. % might be a feasible alternative.
    – ZJR
    Commented Aug 18, 2013 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.