How would an auto-case-fix work with HelloPen and HellOpen? Or indeed, any user created identifier. And if at least one was a global variable in a large program, then it may not be obvious that the variable name is shared, I guess forcing explicit variable declaration would make this issue harder to encounter.

Plus, if the IDE had an auto-complete feature, then it's pretty hard to get variable names or casings wrong.

How would an auto-case-fix work with HelloPen and HellOpen

It wouldn't, which is why:

I would change one of them dramatically to avoid any confusion

I would change one of them dramatically to avoid any confusion

Which is why:

And if at least one was a global variable in a large program, then it may not be obvious that the variable name is shared

then it may not be obvious that the variable name is shared

I wouldn't have any variables with shared names, that's the point of what I am saying. If I had a variable named hellOpen and wanted one called helloPen. Then the IDE would change helloPen to hellOpen, I would see that and change helloPen to greetingsPen.

It is possible that I might miss the IDE changing the fix-up which is why I think that variables should be explicitly declared. Then when I try to declare helloPen I would be given a "variable already exists" error. At which point it would become greetingsPen.

which is why I think that variables should be explicitly declared

That would go a long way towards solving a lot of problems, with or without case sensitivity.

Who is "scraggle"? Will he or she take offense?

Or ... she? He very well might

It seems from several posts that you're not alone and it would be helpful if IanM, Lee or Mike came in and reminded us what the realistic options are.

Well, I'm not sure whether anyone else really wants me to try or not, but I'll give it a go.

The basic choice is based completely on what the compiler expects. It can either be case insensitive (myvar is the same as MYVAR, as in most BASIC's including DBPro, SQL or Pascal(?) ), or not (as in C, Java, BBC BASIC).

Once that choice is made, and if you choose a case-insensitive compiler, then you have to decide how the user interacts with the compiler, and that's done via the IDE. Do you have the IDE auto-correct what the user types or not, and if it does, how it does it.

If you choose a case-sensitive compiler, then the IDE does not need to auto-correct the user (what's the point of typing in case-sensitive code that the IDE then changes for you - you may disagree with this point ).

So the three top-level choices I see are:
- Case-sensitive compiler, no IDE auto-correct.
- Case-insensitive compiler, no IDE auto-correct.
- Case-insensitive compiler, with IDE auto-correct.

If the third option is chosen, then you are into the options specified by Scraggle, which is in what way do you correct what has been entered (not repeating those options here).

Luckily for me, I'm easy with any of these options, so I'll let you all beat each other up over it

No prizes for guessing where my vote lies
With the third option chosen and the IDE auto-correcting there isn't any need to decide in what way to have the IDE auto-correct. All four options could be available to the user. Then we can decide (and change our minds) whenever we want.

The four options for anyone that missed them:
All lowercase: setcameraposition
All uppercase: SETCAMERAPOSITION
lower camel case: setCameraPosition
upper camel case: SetCameraPosition

... and of course there is the fifth option which is actually option 2 from IanM's list.

That is fine for keywords. Variables would be dealt with differently and that discussion has already been thoroughly bashed out above.

If its the commands being case sensitive, then that is what I am against.
If its the variables to be case sensitive, well then I dont really care too much.

commands objectPostion and objectposition and ObjectPosition and OBJECTPOSITION should all compile.

I would prefer variable to be case sensitive. However, I think it's most important to have consistency of case sensitivity throughout the compiler, and I can see that everyone likes to capitalise command names differently, so it may be the best compromise to have everything case insensitive, and make the compiler require you to declare all variables exactly once, and the editor should warn you if you use the same variable name with a different case. There could also be an option in the IDE to automatically fix the casing of commands to any one of the following:
- lowercase
- uppercase
- lower camel case
- upper camel case

I think that covers everyone's main points. I'd go along with that.

so it may be the best compromise to have everything case insensitive, and make the compiler require you to declare all variables exactly once, and the editor should warn you if you use the same variable name with a different case

Agreed. With explicit declaration you have the freedom of case insensitivity without the risks.

Not sure how much work it would be, but actually having an option to switch between implicit and explicit declaration would be great.

Takes longer to write ReadFile than it does readfile, and this will annoy people. You're also not marketing towards open source where there is syntactical standards, but independent developers or studios who want a more powerful pipeline..

I refer you to my previous response re: Extra keypresses

Two-fingered typists are going to be slow no matter what.
Touch-typists have the shift key under each little finger so they're going to be fast no matter what.
For those who are somewhere in the middle, the shift-key is one of the easiest to find - certainly faster than the letters, so there's better justification for shortening commands than avoiding shift as far as speed of typing goes.

@Benjamin,
But how reasonable is it to switch? How can you can a case-sensitive function from a piece of case-insensitive code, or vice-versa? I suspect it'll be implemented as a source-level switch rather than a pragma-type switch.

You're also not marketing towards open source where there is syntactical standards, but independent developers or studios who want a more powerful pipeline..

Open-source has absolutely nothing in the universe to do with coding standards. Nor are coding standards and having a powerful pipeline even remotely related.


As for the compiler switches, I'm against any form of option that would alter the way the code is written, otherwise code snippets wouldn't be the same. The only options there should be are ones that merely alter the binary, like the version/name/icon or are otherwise not required to just run some code.

ut how reasonable is it to switch? How can you can a case-sensitive function from a piece of case-insensitive code, or vice-versa? I suspect it'll be implemented as a source-level switch rather than a pragma-type switch.

You're right. In that case I'm all for implicit declaration and case-sensitivity for identifiers.

I do not like case sensitivity in program code at all (commands, functions, variables).

But having the IDE automatically format the code for me would be great! It would be nice if it could format the code according to my declarations. So I can decide the look of my own functions and variables.

Please, don't include case sensitivity, i nearly pulled my hair out trying to figure out why the print command wouldnt work in python until i figured out it was case sensitive.

A definite no from me!

I vote YES for Case Sensitivity. If that means explicitly declaring them, so be it, I would like to have that option.

The only problem with case sensitive languages is when you are editing the source and the search functionality of that editor is case insensitive.

I agree with GG that case insensitivity encourages sloppy coding, promoting the lack of good programming practice. I am not suggesting that strict-enforcement of case-sensitivity is the solution, but I do think it should be encouraged and recommended.

We are pretty agreed that the majority are voting case insensitivity, and the current AppGameKit compiler is designed around this. That said, we are strongly thinking about having the default IDE provide lazy auto-correction for camel case so if just typed setspriteposition quickly in lower case and look up, by default you would see the IDE adjust it to SetSpritePosition. This can be changed in the preferences, but the default IDE settings would promote readable code and hopefully encourage coders to start adding the capitals themselves.