«

Dave Anderson wrote on 20 jan 2005 in
microsoft.public.inetserver.asp.general:

> Your point may indeed have been avoiding parentheses in VBScript, and
> that's a perfectly acceptible point upon which to differ. In this
> case, I disagree with you. I personally think the presence of
> parentheses makes code more readable.

That is not a subtitute for a principally wrong suggestion that is given by
this habit, that the parentheses are part of the [pseudo] statement, as
they are only a complicated way of describing the parameter expression.

I hope you agree this wrong suggestion is a bad thing in a tutorial
environment, such as this NG.

I your production environment, next to the inevitable extra cpu cycles
introduced in a scripting/interpreting sense [perhaps the parentheses are
deleted by optimizing compiler code?]

> That this happens to be our shop
> standard strongly suggests to me that I am not the only one.

It only suggests to me this shop standard is not educational for new
programmers. Shop standards are no proof of correctnes as such.



--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Evertjan. wrote:
> That is not a subtitute for a principally wrong suggestion that is
> given by this habit, that the parentheses are part of the [pseudo]
> statement, as they are only a complicated way of describing the
> parameter expression.

The parentheses are not superfluous. The Call Statement makes them
*required*. As the Call Statement is part of the Language, it isn't
pseudo-anything.


> I your production environment, next to the inevitable extra cpu cycles
> introduced in a scripting/interpreting sense [perhaps the parentheses
> are deleted by optimizing compiler code?]

This is a fictional concern. There are plenty of good practices that consume
CPU cycles. That does not make them bad practices. CPU cycles are cheap
compared to developer hours.

Following your line of reasoning, we should not use indentation or comments,
since they consume disk space. Good heavens.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

Dave Anderson wrote on 21 jan 2005 in
microsoft.public.inetserver.asp.general:

> Evertjan. wrote:
>> That is not a subtitute for a principally wrong suggestion that is
>> given by this habit, that the parentheses are part of the [pseudo]
>> statement, as they are only a complicated way of describing the
>> parameter expression.
>
> The parentheses are not superfluous. The Call Statement makes them
> *required*. As the Call Statement is part of the Language, it isn't
> pseudo-anything.

No, you are not listening to my argument:

The call statement makes it a [pseudo]function or [pseudo]sub, where it
must adhere to the rules of the use of a function/sub.

The [pseudo]statement should adhere to the statement rules, certainly in
an tutorial sense.

if you use [using two vbscript external examples]:

Response.Write("hello world")

it would be reasonable to use:

Conn.Execute(SQLstring , , 1)

and not understand the generated error.

>> I your production environment, next to the inevitable extra cpu
>> cycles introduced in a scripting/interpreting sense [perhaps the
>> parentheses are deleted by optimizing compiler code?]
>
> This is a fictional concern. There are plenty of good practices that
> consume CPU cycles. That does not make them bad practices. CPU cycles
> are cheap compared to developer hours.

Certainly, but using extra cpu cycles for a bad habit only makes it a
slightly worse habit.

> Following your line of reasoning, we should not use indentation or
> comments, since they consume disk space. Good heavens.

In this NG the concern should not be being in cyberheaven, but in showing
the way to sound coding heaven.

Introdusing the above error by association,
like using Conn.Execute(SQLstring , , 1),
ia not showing the right direction.



--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Evertjan. wrote:

> The call statement makes it a [pseudo]function or [pseudo]sub, where
> it must adhere to the rules of the use of a function/sub.

You can't use the Call statement unless it *IS* a function or sub[1]. What
on earth is your distinction? All you have contrived is a pseudo-name for
something that already has a name.



> if you use [using two vbscript external examples]:
>
> Response.Write("hello world")
>
> it would be reasonable to use:
>
> Conn.Execute(SQLstring , , 1)
>
> and not understand the generated error.

Just as this:

RS = Conn.Execute(SQLString)

could lead to the belief that this is reasonable:

Conn.Execute(SQLString)

As with any language, OF COURSE you need to learn the rules. But please
don't pretend that the above won't generate a perfectly understandable error
message. Are you claiming you have never used (or failed to use) parentheses
ever?

Perhaps you are claiming that the "Cannot use parentheses when calling a
Sub" error message has proved too difficult for you to overcome, and by
extension, so it must be for the rest of the world. In that case, I concede
the point.



> In this NG the concern should not be being in cyberheaven, but in
> showing the way to sound coding heaven.

Sound coding is much more than CPU cycles. If "no parentheses" were such a
great idea to begin with, don't you suppose it would have carried over to
VB.NET?



> Introdusing the above error by association,
> like using Conn.Execute(SQLstring , , 1),
> ia not showing the right direction.

Let's get this straight. Calling a sub with parentheses without using the
Call Statement causes an error. We all know that. But you have done nothing
to show that one solution (learning to use the Call Statement) introduces
more coding errors than another (learning to leave off parentheses).



[1] If you want to play semantics and charge that method is neither, fine.
But as with Functions and Subs, the rules are the same. You can use the Call
Statement (or assignment) together with parentheses, or omit both.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

Dave Anderson wrote on 21 jan 2005 in
microsoft.public.inetserver.asp.general:

>> The call statement makes it a [pseudo]function or [pseudo]sub, where
>> it must adhere to the rules of the use of a function/sub.
>
> You can't use the Call statement unless it *IS* a function or sub[1].
> What on earth is your distinction? All you have contrived is a
> pseudo-name for something that already has a name.
>

Since you don't seem to know what a statement is, and what a function, I
won't cover the rest of your response.

A statement in Basic dialects is a command.
It has to start on a new logical code line.
No code execution is possible without a statement.
A statement cannot return anything.
A new code line can only start with (1) a statement
or (2) a default statement
or (3) be empty.

[The remark statement Rem or ' is just a statement.]
[A line can contain several logical lines separated with a colon [:].


Modern Basics, like vbScript have two default statements:

1 the Let [=asignment] statement has been THE default statement for so
long, that the "let" in itself is no logger available. However theValue =
17 is not a statement by itself in Basic terms, because the underlying
asignment code is that belonging to the original let-statement.

2 The statementized function or sub. This is a defaulting of the call
statement, where the function/sub aquires the habits of a statement,
which I call [pseudo]statement, because it is realy a function/sub.

A function in sensu originalis has to return a value, and could at first,
in historical basic sense, only be used in an expression. A sub
[subroutine] was necessary for callable routines, not having a result.
These subroutines and functuons, not being statements, needed the call
statement for execution [outside an expresion in the case of a function].

An expression, btw, is a string of code that can be parced for a result
value.

========================================

Hereby I rest my case, not wanting to take more time explaining the
principles of basic Basic syntax to you.

Dave, I will not answer a possible reply.

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

Evertjan. wrote:
>>> The call statement makes it a [pseudo]function or [pseudo]sub, where
>>> it must adhere to the rules of the use of a function/sub.
>>
>> You can't use the Call statement unless it *IS* a function or sub[1].
>> What on earth is your distinction? All you have contrived is a
>> pseudo-name for something that already has a name.
>>
>
> Since you don't seem to know what a statement is, and what a
> function, I won't cover the rest of your response.

You appear to be confusing my use of the term "Call Statement" with some
assertion that I am advocating "calling a statement". You are wrong. I am
using it exactly as Microsoft does:
http://msdn.microsoft.com/library/en.../vsstmcall.asp

Given that */CORRECT/* context, the rest of your post makes no sense, as
yours depends on misinterpreting mine.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.