www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - idea: ignore case on reserved words.

reply Tom Popovich <Tom_member pathlink.com> writes:
I'd also like to throw out a thought...

Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
a nice style (upper vs lower) like this

SELECT  name, id, addr
FROM  emp, ...
WHERE  ...;
-----------
UPPER-lower style: all reserved words are written in UPPER-
CASE and all application names are kept in lowercase:

IF TO_NUMBER(the_value) > 22   AND
num1 BETWEEN lval AND hval
THEN
newval := 100;
ELSIF TO_NUMBER (the_valuue) < 1...

--vs--
if to_number(the_value)>22 and
num1 between lval and hval
then
newval := 100;
elsif to_number(the_value) < 1...


e.g another example: the shell loop could be:
FOR  i IN ....
DO
echo $i
DONE




Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for keywords  it
allows your
eye to scan it easily since you can skip/pattern match them.

Maybe we could say :  reserved words can be either lower or uppercase
allowing for this style

--------------------------------
int foo( IN int x, INOUT int y ) { ... }
-vs-
int foo( in int x, inout int y ) { ... }
--------------------------------

or in one of your examples:
--------------------------------
int foo(int x, OUT int y, INOUT int z, int q);
-vs-
int foo(int x, out int y, inout int z, int q);
--------------------------------
that way the IN/OUT... can be easily scanned.


In my C++/C coding, since OUT params can be "hidden"
I always use a ugly
/*OUT*/ in the decl stmts (out of convention).
Jul 19 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cdiemi$157f$1 digitaldaemon.com>, Tom Popovich says...

Maybe we could say :  reserved words can be either lower or uppercase
allowing for this style

Well that would seriously bugger up my class Int. Arcane Jill
Jul 19 2004
parent "Vathix" <vathixSpamFix dprogramming.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cdifjr$15hj$1 digitaldaemon.com...
 In article <cdiemi$157f$1 digitaldaemon.com>, Tom Popovich says...

Maybe we could say :  reserved words can be either lower or uppercase
allowing for this style

Well that would seriously bugger up my class Int. Arcane Jill

Even worse, Windows' LONG is an int in D...
Jul 21 2004
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 20 Jul 2004 06:39:14 +0000 (UTC), Tom Popovich wrote:

 I'd also like to throw out a thought...
 
 Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
 a nice style (upper vs lower) like this
 
 SELECT  name, id, addr
 FROM  emp, ...
 WHERE  ...;
 -----------
 UPPER-lower style: all reserved words are written in UPPER-
 CASE and all application names are kept in lowercase:

This one of the things that I do *not* miss from my COBOL days. It seems to imply that keywords are more important that user words, and it's generally the user words (identifiers) that you need to have stand out. Now-a-days I just use a good colorizing editor to highlight/lowlight keywords. -- Derek Melbourne, Australia 20/Jul/04 5:15:56 PM
Jul 20 2004
prev sibling next sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
I'd also like to throw out a thought...

Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
a nice style (upper vs lower) like this

SELECT  name, id, addr
FROM  emp, ...
WHERE  ...;
-----------
UPPER-lower style: all reserved words are written in UPPER-
CASE and all application names are kept in lowercase:

IF TO_NUMBER(the_value) > 22   AND
num1 BETWEEN lval AND hval
THEN
newval := 100;
ELSIF TO_NUMBER (the_valuue) < 1...

--vs--
if to_number(the_value)>22 and
num1 between lval and hval
then
newval := 100;
elsif to_number(the_value) < 1...

[snip]
Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for keywords  it
allows your
eye to scan it easily since you can skip/pattern match them.

Looks totaly ugly to me. And we have editors that can colorise the keywords!!! -- Matthias Becker
Jul 20 2004
parent reply Tom Popovich <Tom_member pathlink.com> writes:
But isn't it easier to read the first one when you don't have 
a syntax highlighted/colored editor?

--------------------------------
int foo(int x, OUT int y, INOUT int z, int q);
-vs-
int foo(int x, out int y, inout int z, int q);
--------------------------------


I'm proposing that users can "opt in" mixed case, when it helps
readability.

Implemention is easy: the compiler will
just lowercase a word before searching the symbol table of reserved words.
[And it would treat  INOUT / inout  the same].


In article <cdikjt$18ni$1 digitaldaemon.com>, Matthias Becker says...
I'd also like to throw out a thought...

Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
a nice style (upper vs lower) like this

SELECT  name, id, addr
FROM  emp, ...
WHERE  ...;
-----------
UPPER-lower style: all reserved words are written in UPPER-
CASE and all application names are kept in lowercase:

IF TO_NUMBER(the_value) > 22   AND
num1 BETWEEN lval AND hval
THEN
newval := 100;
ELSIF TO_NUMBER (the_valuue) < 1...

--vs--
if to_number(the_value)>22 and
num1 between lval and hval
then
newval := 100;
elsif to_number(the_value) < 1...

[snip]
Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for keywords  it
allows your
eye to scan it easily since you can skip/pattern match them.

Looks totaly ugly to me. And we have editors that can colorise the keywords!!! -- Matthias Becker

Jul 20 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
But isn't it easier to read the first one when you don't have 
a syntax highlighted/colored editor?

--------------------------------
int foo(int x, OUT int y, INOUT int z, int q);
-vs-
int foo(int x, out int y, inout int z, int q);
--------------------------------


I'm proposing that users can "opt in" mixed case, when it helps
readability.

Nope. int is reserved! So you'd get: INT foo(INT x, OUT INT y, INOUT INT z, INT q); And no, sorry I can read the lowercase version faster and more easy. INT fac (INT x) { IF (x <= 1) RETURN 1; ELSE RETURN x * fac(x - 1); } No, noway. this is totaly confusing me. In SQL the commands normaly are formated diffrently to other programminglanguages: select * from table where foo = bar SELECT * FROM table WHERE foo = bar This seperates the lines where you use commands from those where you don't visualy. In D and most other programming-languages language defined constructs and userdefined constructs are mixed togther. And you'd get a inconsitency in the language and that is something nobody likes. there is a property "init" build into the language for trivial types. For ayou own types you have to define init on your own. Now imagine that on the buildinversion case is ignored but on your own it isn't. That would be realy iritating. -- Matthias Becker
Jul 21 2004
parent teqDruid <me teqdruid.com> writes:
On Wed, 21 Jul 2004 09:08:34 +0000, Matthias Becker wrote:

 
 INT fac (INT x)
 {
 IF (x <= 1)
 RETURN 1;
 ELSE
 RETURN x * fac(x - 1);
 }
 }
 

Heh. Looks kinda like BASIC.
Jul 21 2004
prev sibling next sibling parent reply Chris Lawson <cl mangler.tinfoilhat.ca> writes:
Mixing the case makes it a huge pain in the ass to do any kind of 
grepping.  Regardless of editor, easily grep-able source is important.

I usually find the uppercase distracting in SQL, but that's largely a 
style issue, I suppose.

Chris

Tom Popovich wrote:

 I'd also like to throw out a thought...
 
 Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
 a nice style (upper vs lower) like this
 
 SELECT  name, id, addr
 FROM  emp, ...
 WHERE  ...;
 -----------
 UPPER-lower style: all reserved words are written in UPPER-
 CASE and all application names are kept in lowercase:
 
 IF TO_NUMBER(the_value) > 22   AND
 num1 BETWEEN lval AND hval
 THEN
 newval := 100;
 ELSIF TO_NUMBER (the_valuue) < 1...
 
 --vs--
 if to_number(the_value)>22 and
 num1 between lval and hval
 then
 newval := 100;
 elsif to_number(the_value) < 1...
 
 
 e.g another example: the shell loop could be:
 FOR  i IN ....
 DO
 echo $i
 DONE
 
 
 
 
 Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for keywords  it
 allows your
 eye to scan it easily since you can skip/pattern match them.
 
 Maybe we could say :  reserved words can be either lower or uppercase
 allowing for this style
 
 --------------------------------
 int foo( IN int x, INOUT int y ) { ... }
 -vs-
 int foo( in int x, inout int y ) { ... }
 --------------------------------
 
 or in one of your examples:
 --------------------------------
 int foo(int x, OUT int y, INOUT int z, int q);
 -vs-
 int foo(int x, out int y, inout int z, int q);
 --------------------------------
 that way the IN/OUT... can be easily scanned.
 
 
 In my C++/C coding, since OUT params can be "hidden"
 I always use a ugly
 /*OUT*/ in the decl stmts (out of convention).
 
 

Jul 20 2004
parent Berin Loritsch <bloritsch d-haven.org> writes:
Chris Lawson wrote:

 Mixing the case makes it a huge pain in the ass to do any kind of 
 grepping.  Regardless of editor, easily grep-able source is important.
 
 I usually find the uppercase distracting in SQL, but that's largely a 
 style issue, I suppose.
 

IMO, its an all or nothing proposition. In SQL it is ALL case insensitive. In D, C, C++, Java, C#, Objective C, Visual Basic, etc. it is all case sensitive. Having the keywords case insensitive but the variables case sensitive is more confusing, and would lead to stupid errors.
Jul 20 2004
prev sibling next sibling parent reply Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjuxNO SPAMyahoo.es> writes:
Tom Popovich wrote:
 
 or in one of your examples:
 --------------------------------
 int foo(int x, OUT int y, INOUT int z, int q);
 -vs-
 int foo(int x, out int y, inout int z, int q);
 --------------------------------
 that way the IN/OUT... can be easily scanned.

I know I'm exposing to some serious flames by saying this (in a C alike language forum), but I actually like that style. A good editor would automatically put the keywords in uppercase so you don't have to do it by hand. Anyway (second tought :) good editors put the keywords in flashy colors so it's not that much of an improvement.
Jul 20 2004
parent Berin Loritsch <bloritsch d-haven.org> writes:
Juanjo Álvarez wrote:

 Tom Popovich wrote:
  
 
or in one of your examples:
--------------------------------
int foo(int x, OUT int y, INOUT int z, int q);
-vs-
int foo(int x, out int y, inout int z, int q);
--------------------------------
that way the IN/OUT... can be easily scanned.

I know I'm exposing to some serious flames by saying this (in a C alike language forum), but I actually like that style. A good editor would automatically put the keywords in uppercase so you don't have to do it by hand. Anyway (second tought :) good editors put the keywords in flashy colors so it's not that much of an improvement.

I'll be honest. I am leery of anything changing my code automatically unless there is a real perceived benefit. For example, changing case is not a real benefit--it's like changing the EOL character in a file, it can screw up merge processes in version control software. However, refactoring tools are quite welcome (how many times have you wanted to change the name of a method to make it clearer and then spent hours tracking down where the method was called?). You know, I really don't care if the official syntax is upper, lower, or title case--I'd just like the case policy to be similar to the policy for the variables.
Jul 20 2004
prev sibling next sibling parent "Zz" <Zz Zz.com> writes:
Like Modula-2.
I really like Modula-2 and this is the only thing I really dislike about the
language.

This will not happen.

GG.

"Tom Popovich" <Tom_member pathlink.com> wrote in message
news:cdiemi$157f$1 digitaldaemon.com...
 I'd also like to throw out a thought...

 Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
 a nice style (upper vs lower) like this

 SELECT  name, id, addr
 FROM  emp, ...
 WHERE  ...;
 -----------
 UPPER-lower style: all reserved words are written in UPPER-
 CASE and all application names are kept in lowercase:

 IF TO_NUMBER(the_value) > 22   AND
 num1 BETWEEN lval AND hval
 THEN
 newval := 100;
 ELSIF TO_NUMBER (the_valuue) < 1...

 --vs--
 if to_number(the_value)>22 and
 num1 between lval and hval
 then
 newval := 100;
 elsif to_number(the_value) < 1...


 e.g another example: the shell loop could be:
 FOR  i IN ....
 DO
 echo $i
 DONE




 Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for

 allows your
 eye to scan it easily since you can skip/pattern match them.

 Maybe we could say :  reserved words can be either lower or uppercase
 allowing for this style

 --------------------------------
 int foo( IN int x, INOUT int y ) { ... }
 -vs-
 int foo( in int x, inout int y ) { ... }
 --------------------------------

 or in one of your examples:
 --------------------------------
 int foo(int x, OUT int y, INOUT int z, int q);
 -vs-
 int foo(int x, out int y, inout int z, int q);
 --------------------------------
 that way the IN/OUT... can be easily scanned.


 In my C++/C coding, since OUT params can be "hidden"
 I always use a ugly
 /*OUT*/ in the decl stmts (out of convention).

Jul 21 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Tom Popovich wrote:

I'd also like to throw out a thought...

Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
a nice style (upper vs lower) like this

SELECT  name, id, addr
FROM  emp, ...
WHERE  ...;
-----------
UPPER-lower style: all reserved words are written in UPPER-
CASE and all application names are kept in lowercase:

IF TO_NUMBER(the_value) > 22   AND
num1 BETWEEN lval AND hval
THEN
newval := 100;
ELSIF TO_NUMBER (the_valuue) < 1...

--vs--
if to_number(the_value)>22 and
num1 between lval and hval
then
newval := 100;
elsif to_number(the_value) < 1...


e.g another example: the shell loop could be:
FOR  i IN ....
DO
echo $i
DONE




Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for keywords  it
allows your
eye to scan it easily since you can skip/pattern match them.

Maybe we could say :  reserved words can be either lower or uppercase
allowing for this style

--------------------------------
int foo( IN int x, INOUT int y ) { ... }
-vs-
int foo( in int x, inout int y ) { ... }
--------------------------------

or in one of your examples:
--------------------------------
int foo(int x, OUT int y, INOUT int z, int q);
-vs-
int foo(int x, out int y, inout int z, int q);
--------------------------------
that way the IN/OUT... can be easily scanned.


In my C++/C coding, since OUT params can be "hidden"
I always use a ugly
/*OUT*/ in the decl stmts (out of convention).


  

typing fluently because you halve the productivity (as your only typing with one hand). Caps lock is even worse. Also uppercase is harder for me to read as I'm less used to it and have to switch neurons in my brain (like most people), which makes it harder to read code like reading a book. http://en.wikipedia.org/wiki/Uppercase_letter http://www.omegalegal.com/Articles/StopAllCaps.htm -- -Anderson: http://badmama.com.au/~anderson/
Jul 21 2004
parent reply Sampsa Lehtonen <Sampsa_member pathlink.com> writes:
In article <cdlocd$2lmo$1 digitaldaemon.com>, J Anderson says...
Tom Popovich wrote:

I'd also like to throw out a thought...

Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
a nice style (upper vs lower) like this

Personally, I don't like holding now shift for more then one letter when typing fluently because you halve the productivity (as your only typing with one hand). Caps lock is even worse. Also uppercase is harder for me to read as I'm less used to it and have to switch neurons in my brain (like most people), which makes it harder to read code like reading a book.

For sql syntax the caps work just fine, but with c-style format they don't look nice. Many formatting guidelines suggest that all-caps are used for constants. The one for D language tells the same. Personally I'm used to see the reserved words in different colors/formatting in the editor, so that they are more easily distinguished. What comes to the typing speed I don't see any problem in typing all-caps words. I rest my index finger (or whatever the last finger counting on the thumb is called... can't remember :) on the shift all the time. So typing speed doesn't certainly get halved. Sampsa Lehtonen
Jul 21 2004
parent Berin Loritsch <bloritsch d-haven.org> writes:
Just consider the repercussions of any existing software.  For example, 
there is an "Int" class, since Int would be the same as "int" if the
case were suddenly not to matter--it would cause the entire class to be 
renamed.

Also consider distinguishing between constants and keywords if someone 
were to do the all caps thing.

I personally am not a fan of the idea.

SQL has its place, but it is also ALL case insensitive.  That means that 
the user has the option to have the keywords all upper case, or the 
column and table names all upper case, or everything in one case.  What 
ends up happening is that unless the SQL is maintained by one person or 
a tool, different ideas creep in and one part has different 
capitalization policies in the same file.  Not pretty.

Since D seems to favor encouraging good practices, why change the 
capitalization policy at this point?

There are repercussions of changing the case now and later.  Now we 
would have to deal with software that used to compile not compiling 
after the change due to variable and class name conflicts.  In the 
future we will have to deal with software not compiling because one 
maintainer used title case for the keywords, another used all caps, and 
yet another used all lower case in the same file.

The cost of even experimenting with this in the D language would be too 
high IMO.
Jul 21 2004