Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update (change?) Rule: All code should be in lower case #57

Closed
RichardSoule opened this issue Sep 6, 2019 · 2 comments · Fixed by #86
Closed

Update (change?) Rule: All code should be in lower case #57

RichardSoule opened this issue Sep 6, 2019 · 2 comments · Fixed by #86
Assignees
Labels
enhancement New feature or request

Comments

@RichardSoule
Copy link

Existing Rule 1: Keywords are written uppercase, names are written in lowercase.

Science teaches us that this isn't as good as just having all code in lower case. In the very old days when every code editor was black on white (or green on black, or amber on black) this could 'help' us by delineating keywords. However, these days just about every editor does keyword coloring/highlighting so this isn't the 'help' that it once was. See things like: https://uxmovement.com/content/all-caps-hard-for-users-to-read/

If you adopt this standard then you'll spend a lot of time using shift lock and/or holding down your shift key... And for zero gain.

We use the 'All code should be in lower case' rule and it works great. Interestingly I got some new interns this week and one of them mentioned "Yeah, lower case just looks more modern. All that upper case stuff makes me think of old DBAs."

@PhilippSalvisberg PhilippSalvisberg added enhancement New feature or request help wanted Extra attention is needed labels Sep 7, 2019
@PhilippSalvisberg
Copy link
Collaborator

I think we need to add a paragraph explaining that being consistent is more important. If you do not agree to these rules/guidelines you can fork the repo and amend them.

I agree, that using upper case letters to emulate syntax coloring is wrong. In the utPLSQL core project we use lower case for everything and this works well.

In fact there is another problem with this rule, when violating the rule "Never use ORACLE keywords as names.". This happens quite often, even by Oracle, e.g. when using these keywords as column names:

  • name
  • document
  • content
  • size
  • version

Writing them in upper case letters is and feels wrong. The same thing applies to other identifier names (packages, functions, procedures). So manually applying this rule is difficult and automatically applying them leads to wrong results.

I think it is time to change that.

@S-Koell
Copy link

S-Koell commented Mar 5, 2020

I think we need to add a paragraph explaining that being consistent is more important. If you do not agree to these rules/guidelines you can fork the repo and amend them.

I agree. These guidelines shouldn't specify a specific style. Maybe a recommendation.

Coming from JAVA I would eg prefer lowercase and upper for constants.I think it is much more readable that way. But others will surely disagree ;)

@kibeha kibeha self-assigned this Sep 2, 2020
kibeha added a commit to kibeha/plsql-and-sql-coding-guidelines that referenced this issue Sep 2, 2020
…ason and importance of consistency. Converted all code examples to lowercase (thanks Philipp for https://www.salvis.com/blog/2020/08/28/formatting-sql-code-blocks-in-markdown-files/ )
kibeha added a commit to kibeha/plsql-and-sql-coding-guidelines that referenced this issue Sep 16, 2020
…samples that automatic script didn't handle. Fixed a few typos along the way.
@kibeha kibeha removed the help wanted Extra attention is needed label Oct 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants