frankdilu / CheLang

CheLang es un lenguaje de programación esotérico argento. Ni más, ni menos. Es la que va.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Keyword casing

soypat opened this issue · comments

It is my understanding the language's creator wishes to maintain camelCase as the capitalization scheme for keywords. Here are some of my worries that come to mind when I think of using a language with such a scheme.

Ambiguity due to informal writing

Keyword Possible interpretations
nakever naKeVer, nakeVer
maomeno maOMeno, maoMeno

As you can see, there are other non-obvious ways to write the same keyword made of more than a single word. This problem is highlighted by the discrepancy between two keywords that should follow the same convention but have different criteria for the capitalization:

menorOIgual and maomeno

This can be solved by applying a rule such as leaving one-letter-words lower case though this would arguably make reading harder. camelCase could be applied to all keywords so as to have maOMeno. It could also be argued all-lower case would fit in with the informal nature of the language, as no one really writes naKeVer in their day to day life.

Separating keyword style from variable naming and possible function naming (future-proofing)

We all know camelCase is best, there is no room for argument here. That's why I use it for all my variable names, and you should too! Forcing camelCase upon keywords may take away from readability if everything is camelCase.

Proposal

Keywords should be short and memorable and are to the point, this is why they in theory should not benefit from capitalization schemes. Variables on the other hand carry only the meaning their creator gives them, which may end up being a few dozen characters long. Variables do benefit from naming schemes and are where people should be forced to write in camelCase, PascalCase, etc.

Flexibilize cap-scheme of keywords or make them lowercase altogether.

Got it, you right.
Im considering do it not cAsE sEnSiTiVe... Or probably the best will be separe that words and done hahahahah.

Soon update.

Commit update:
No cAsE sEnSiTiVe Done.
Separate "andaPor" and "poneleQue" Done.
The most of keywords will change to shorters and more memorables versions. But i dont have ideas yet.

If there are no more things, i close the issue tomorrow.