Separators inside a var name

[Rainy]

On Jun 9, 5:34 pm, Alexander Schmolck <a.schmo... at gmail.com> wrote:
> Rainy <andrei.... at gmail.com> writes:
> > 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. From what I understand,
> > scheme can have variables like var-name. I'm curious about reasons
> > that python chose to disallow this.
>
> Legacy -- mathematical notation is broken and conflates negation and
> subtraction (causing all sorts of annoyances including this one). Thus if you
> want to be able to name a variable ``a-b`` you either have to write ``a - b``
> to disambiguate subtracton from the variable name ``a-b`` or you need to chose
> a different symbol for subtraction (writing "a ~ b" would likely be the best
> choice).

~ is terrible, imho, I'd much rather disallow a - b for subtraction
(and all
math ops).

>
> > Another question I have is what other languages allow this naming scheme?
>
> All lisps. Dylan. Rebol. Postscript. Forth. I'm sure there are a few others.
>
> > Were there any languages that allowed space as a separator?
>
> Sure.
>
> > What would be a practical way to separate variables from keywords in that
> > case?
>
> Lisp allows you to use pretty much anything in a variable name, you just have
> to quote it, either
>
>  like\ this
>
> or
>
>  |like this|

This is actually pretty nice. I think I like this much better
than C/Java/etc convention. I wouldn't use pipes but I'd pick
something that's easy to type and is nicely readable. Not
sure what..

>
> > "some long variable name", 'just a string', or maybe using 2 spaces: one var
> > + other var + third var ? I think being able to easy have very long names
> > for vars that are easy to type would be a fairly significant advantage.
>
> I assume you haven't programmed too much? The problem with long names is that
> they obscure structure, so they are only worthwhile for rarely used and fairly
> obscure concepts where the added descriptiveness yields a net advantage.

Only about 8 years, but it may be that I'm just
not very good ;-). I'm not sure that's the case.
My problem with long names is that they look
ugly, and the longer they are, the uglier they
look when you use underscores or caps. Other
than that, I'd like to have an option to use
longer names. Maybe it won't be used all the
time, but still..

>
> > I know I'm probably being too obsessive about this, but that didn't stop me
> > from posting. Comments?
>
> I think you're right -- the common naming convention's suck and "python's" is
> particularly bad (HtmlFrob HTMLFrob htmlFrob html_frob htmlfrob HTML_FROB
> HTMLFROB -- which one will it be? No way to know without looking at the rest
> of the code, the only consistency is that the last two are mostly used for
> constants; everything else is completely up for grabs). You'd better get used
> to it though, it's become "standardized".
>
> 'as

Well, I agree, this is terrible. If I were Guido I'd
make a very explicit rule that a certain naming
scheme is preferred and other schemes are very bad.
And I'd get it in the beginning of official tutorial,
libref, in books, etc. Mostly it's ClassName and func_name
and var_name and so on, but very often it's something else.
BUT even if that was the rule and everyone followed it,
though it would be much better than what we have now,
it would still offend my taste. Just saying!