Separators inside a var name

Rainy andrei.avk at
Mon Jun 9 22:38:17 CEST 2008

On Jun 9, 2:05 pm, "Sebastian \"lunar\" Wiesner"
<basti.wies... at> wrote:
>  Rainy <andrei.... at> at Montag 09 Juni 2008 19:29:
> > I have a stylistic question. In most languages words in var. name are
> > separated by underscores or cap letters, resulting in var names like
> > var_name, VarName and varName. I don't like that very much because all
> > 3 ways of naming look bad and/or hard to type.
> Then you better get used to such names, as they are common for many widely
> spread languages including C, C++, C#, Java, Python, Ruby, Perl and many
> more ;)  You may like these or dislike these names, but you won't come
> around them ;)

Well, I was thinking of using some obscure language for personal
that may not need good libs, etc. But of course I agree that there are
no mainstream widely used languages that allow this.

> > From what I understand, scheme can have variables like var-name. I'm
> > curious about reasons that python chose to disallow this.
> "-" is an operator in Python.  How should the parser know,
> whether "var-name" means "the object bound to var_dash_name" or "subtract
> the object bound to name from the object bound to var"?

As I mentioned in another post, differentiate between var1 - var2 and

> Scheme can allows such names, because its a functional programming language.
> Subtracting in this language is not done through operators, but through
> functions.  Therefore there is a clear difference between referencing a
> name or subtracting two ones: var-name vs (- var name).
> > Another question I have is what other languages allow this naming scheme?
> Other lisp dialects do, due to the same reasons as scheme.  
> > Were there any languages that allowed space as a separator?
> None that I know of.  Probably one could use unicode characters, that look
> like a space in languages, which allow unicode characters in identifiers
> (as Java or C#, iirc), but I doubt this.  Anyway, even if allowed, this
> would be silly, since it obscures code to the eyes of the reader.

Yes, that's of course out. I meant using real space.

> > What would be a practical way to separate variables from keywords in that
> > case? "some long variable name", 'just a string', or maybe using 2 spaces:
> > one var  +  other var  +  third var ?
> I can't image a practical way to allow a space as character in names, while
> still maintaining it syntactic element for separation of names.  Quotes are
> normally used for string or characters literals and a double space is hard
> to distinguish from a single space, and things like ${a name with spaces}
> is a lot nastier than names with underscores (which aren't bad at all,
> imho).

I agree about ${name with spaces}. I would be interested in the
of using something else for strings and using quotes for var names.
perfect either but might be better than underscores...

> > I think being able to easy have very long names for vars that are easy to
> > type would be a fairly significant advantage.
> Names shouldn't be long, they should be expressive.  If you can't give an
> object a _short_, but _expressive_ name, your object is too complicated ;)

I'm not sure, I often find myself needing to use 4 words for var name,
then underscores I think don't look too good, I would say that
are kind of ok for 2 words, not very good for 3 words and bad for 4+
I think if spaces were allowed, I would sometimes use 5 word

> Btw, I don't really understand your refusal of underscores.  In my opinion
> such names are harder to read than underscores, which look more like a real
> space, because the leave a space in the middle of a line, that you look at.
> If they are too hard for you to type, whats the point in swapping the dash
> and the underscore in your keyboard layout?

To me, underscores_look_very_ugly. What_if_I_typed
with_an_underscore? Ugly! Swapping the dash and underscore are not a
idea, it doesn't fix uglyness, though, and it adds a problem if you
to work on another system, because you will always type dash by
(which will look nice but won't work ;-) ).

More information about the Python-list mailing list