"non-essential difficulty" - case enforcing?

[Shae Erisson]

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? :)


how-much-of-the-success-of-VB-is-because-of-its-spiffy-IDE-ly y'rs
-- 
sHae mAtijs eRisson (sHae at wEbwitchEs.coM) gEnius fOr hIre
   bRing mE fIve sQuirrels aNd nO oNe wIll gEt hUrt