"non-essential difficulty" - case enforcing?
shapr at uab.edu
Wed May 31 17:01:12 CEST 2000
Aahz Maruch wrote:
> <grin> I've read my Brooks, too. Thing is, I'd almost agree with you
> that case sensitivity is an accidental difficulty for *writing* code,
> but I absolutely disagree that case sensitivity is an accidental
> difficulty for *reading* code. Which is the point that I was making
> about indentation.
> i tHinK You woULd aGrEe thAt tHiS iS HarDer TO reAd. But it's not much
> harder to write....
I do agree with the writing versus reading, that's why I agreed with (or
elaborated on, I don't remember) an earlier post and ended up suggesting
that case be enforced according to certain standards in the output. I
haven't come up with a good standard, but I think one could be designed.
I also agree with the idea that an IDE or editor could do case-enforcing
and allow case-sensitivity to remain. I don't know how hard that would
be to implement though.
In summary, case-enforcing seems like it could be a solution, I just
don't know how it would work :)
Could anyone suggest a workable case-enforcing policy?
The only other way I can think of to get around the case problem and not
get rid of case sensitivity is to have an IDE that's smart enough to
figure out when a variable or name is being created versus when it's
being modified and change the highlighting accordingly. That's something
I would know how to do, and I don't think it would be difficult. My
reasoning for that solution is that when I get confused about case, it's
because I am working with a new variable when I thought I was working
with one I already had. Are there other cases of problems? :)
sHae mAtijs eRisson (sHae at wEbwitchEs.coM) gEnius fOr hIre
bRing mE fIve sQuirrels aNd nO oNe wIll gEt hUrt
More information about the Python-list