digitalmars.D - idea: ignore case on reserved words.
- Tom Popovich (45/45) Jul 19 2004 I'd also like to throw out a thought...
- Arcane Jill (3/5) Jul 19 2004 Well that would seriously bugger up my class Int.
- Vathix (3/8) Jul 21 2004 Even worse, Windows' LONG is an int in D...
- Derek Parnell (10/21) Jul 20 2004 This one of the things that I do *not* miss from my COBOL days. It seems...
- Matthias Becker (3/26) Jul 20 2004 Looks totaly ugly to me. And we have editors that can colorise the keywo...
- Tom Popovich (13/43) Jul 20 2004 But isn't it easier to read the first one when you don't have
- Matthias Becker (35/44) Jul 21 2004 Nope. int is reserved!
- teqDruid (2/12) Jul 21 2004 Heh. Looks kinda like BASIC.
- Chris Lawson (6/68) Jul 20 2004 Mixing the case makes it a huge pain in the ass to do any kind of
- Berin Loritsch (6/12) Jul 20 2004 IMO, its an all or nothing proposition. In SQL it is ALL case
- Juanjo =?ISO-8859-15?Q?=C1lvarez?= (7/14) Jul 20 2004 I know I'm exposing to some serious flames by saying this (in a C alike
- Berin Loritsch (11/28) Jul 20 2004 I'll be honest. I am leery of anything changing my code automatically
- Zz (8/53) Jul 21 2004 Like Modula-2.
- J Anderson (11/57) Jul 21 2004 Personally, I don't like holding now shift for more then one letter when...
- Sampsa Lehtonen (11/22) Jul 21 2004 For sql syntax the caps work just fine, but with c-style format they don...
- Berin Loritsch (23/23) Jul 21 2004 Just consider the repercussions of any existing software. For example,
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
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 styleWell that would seriously bugger up my class Int. Arcane Jill
Jul 19 2004
"Vathix" <vathixSpamFix dprogramming.com> "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...Even worse, Windows' LONG is an int in D...Maybe we could say : reserved words can be either lower or uppercase allowing for this styleWell that would seriously bugger up my class Int. Arcane Jill
Jul 21 2004
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
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
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
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
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
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
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 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
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
Juanjo Álvarez wrote:Tom Popovich wrote: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.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
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 forkeywords itallows 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
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).
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.
http://en.wikipedia.org/wiki/Uppercase_letter
http://www.omegalegal.com/Articles/StopAllCaps.htm
--
-Anderson: http://badmama.com.au/~anderson/
Jul 21 2004
In article <cdlocd$2lmo$1 digitaldaemon.com>, J Anderson says...Tom Popovich wrote: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 LehtonenI'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 thisPersonally, 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.
Jul 21 2004
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