Re: Current coding standard documentation


"Chris Burrows" <cfbsoftware@xxxxxxxxxxx> wrote in message news:454eaa10@xxxxxxxxxxxxxxxxxxxxxxxxx
"42" <life@xxxxxxxxxxxxxxxxxxx> wrote in message
news:454bd0c9$1@xxxxxxxxxxxxxxxxxxxxxxxxx

"Chris Burrows" <cfbsoftware@xxxxxxxxxxx> wrote in message
news:4548187d@xxxxxxxxxxxxxxxxxxxxxxxxx

Actually the beginning of this syntax style was ALGOL. Wirth fixed up a
few
of ALGOL's problems in Pascal but didn't resolve the others until
Modula-2.
The fixes that elegantly avoid the semicolon problems, dangling elses
etc.
etc. are:

IF ... END
IF ... ELSE ... END
IF ... ELSIF ... ELSIF ... ELSE ... END

(not a BEGIN in sight)

What we need is a SELECT statement:

select
when condition then statement
when condition then statement
:
when condition then statement
[otherwise statement]
end

OK - not a bad idea on first sight, but on closer inspection, we have two
new keywords and an alternative use for an existing one, where one new one
keyword is necessary and sufficient. There is also added redundancy.

Note that the introduction of keywords (particularly commonly used words) in
an existing language (particularly one that is case-insensitive) needs to be
done with utmost care to avoid clashes with existing code. This is much
harder to resolve with mechanical translation / migration tools than the
other syntactic changes involved in this discussion.

To illustrate what I mean, consider the case where there is only one
selection:

select when condition then
statement
otherwise
statement
end

This is totally redundant as it is just a more verbose form of the 'if then
else'. If we substitute 'if' for 'select when' and 'else' for 'otherwise' it
reduces to

if condition then
statement
else
statement
end

Of course, having a completely redundant statement like 'case' is fine, right? :)
After all, you can write the same code using only if then else. Oh, and naturally,

case expr0 of
expr1 : statement1;
else statement
end

can be written as

if expr0 = expr1 then
statement1
else
statement

but it's clear that when someone uses the case statement instead of the if
statement, it's an obvious indication that that part of code will probably
be extended in the future (or contained more in the past).

Moreover, we can eliminate the compound statement as well, they are
completely redundant. Why write

if cond then
begin
statement1;
:
statementN
end;

when

proc1: procedure;
begin
statement1;
:
statementN
end;

if cond then
proc1;

does the same thing?

All we then need to do is introduce a new keyword 'elsif' instead of the
more common usage keyword 'when' and we have:

if condition then
statement
elsif condition then
statement
elsif condition then
statement
else
statement
end

which gets us back to the way it has been successfully done for decades in
other languages.

I dislike this construct because I think it does nothing to make the code look
more readable. More if then else is exactly the opposite of what I want. The
SELECT statement (similarly to the CASE statement) makes the code much
cleaner. (While we are at it, I would like to be able to use OTHERWISE
instead of ELSE in the CASE statements as well!)

I always hated the concept of reserved words (and null terminated strings,
but that's another topic) as in my opinion it hinders the development of the
language. There are many things that could be added to the language if we
just got rid of the concept. However, since it is unlikely to happen to Delphi,
why not make a bunch of extensions and have a compiler switch that people
can use? This way the backward compatibility is maintained and at the same
time new projects can take advantage of the language extensions.

For example, in addition to the above suggestions, I would love to see the
addition of rol/ror operators and the for var := expr to|downto expr BY expr
construct, and other things that would help make the code considerably easier
to write and maintain.



.

Relevant Pages

  • Re: Macro Question: Paraphrasing
    ... why not use keywords for everything? ... that keywords can distort the meaning of a symbol on the surface level, ... which is the language used by the human reader to map symbols to ... language is by convention read right to left. ...
    (comp.lang.lisp)
  • Re: Generics?
    ... at fault, not the language. ... The system-defined parameter-less constructor initializes all fields ... case inside switch statement? ... set of names as identifiers because those are c# keywords - that's OK. ...
    (borland.public.delphi.non-technical)
  • Re: Named parameters?
    ... >> I do not like distingishing characters(even for the set thing we talked ... C# is more a "keyworded language". ... > The problem is that you cannot add keywords afterwards, ... This can be hard to do, because its so easy to say you want to reserve: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: will Fortran introduce key word in the future standard?
    ... so I believe introduction of keywords is a reasonable limitation ... and the resulting language is a safer and more reliable one. ... standard and can cause problems if you acidentally use them. ...
    (comp.lang.fortran)
  • Re: Writing good formatted SQL
    ... this in the early days of software engineering when I was at AIRMICS ... The keywords are seen as whole units and are not read. ... Capitalized proper nouns is an English and Germanic convention; ... the use of plural and collective nouns is language specific ...
    (microsoft.public.sqlserver.programming)
Loading