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).

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

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

>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

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
>
>

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).
> 
> 

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.

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.

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.

>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