No spaces within commands
Always brackets around command parameters
cap first letter in each command word like: LoadImage

it cant be that hard to test after a comma if there is a space first before the value...

I think you misunderstood the question. It is whether to have spaces in command names, not spaces between parameters

eg.
If we chose to use upper camel-case and brackets, the two options would be the following.

With spaces:


Without spaces:

1) No Spaces
2) No object numbers
3) Case insensitive

Here is an example of what I mean:



Why use spaces and object numbers when you can use variables?
Now, I know that myimage is storing "yourimage.png" inside of it.

@DMXtra that will only work if u can control myimage OO.
eg
myimage.Width = 100;

yimage.Width = 100;

Not really, myimage could be an integer. I imagine there will be functions like PasteImage no matter what, and these would take images in the form of whatever LoadImage returns, of course I would prefer them to be objects, that way you can write functions that only allow you to pass images, this requires less checking and makes it harder to break your code by passing the wrong thing.

Huh? The code could simply return an integer or a pointer. It doesn't have to be an object at all.

Hi guys,

Very nice so far great idea's. Well here is my 2 cents.
How about something very easy that is really flexible something like this.

I've got rather confused by the brackets discussion. What exactly is being suggested? Which commands would require brackets? What about things like sync, repeat, end? What precisely is the defining characteristic of a function compared to a command?

@GG
In DBPro there are two types of commands. Ones that return a value and ones that don't. Ones that return a value require you to use () to call them, ones that don't return a value require you to not use ().

What is being suggested here is to use () to call commands regardless of whether they return a value or not.
ie.


Statements like 'do' and 'loop' would not use () though as they are part of the language rather than a command.

In DBPro there are two types of commands. Ones that return a value and ones that don't. Ones that return a value require you to use () to call them, ones that don't return a value require you to not use ().

Yes I know.

Statements like 'do' and 'loop' would not use () though as they are part of the language rather than a command.

That's precisely my question. What do you mean exactly? When is a piece of code defined to be a "command" rather than a "part of the language"? Why should, for example, "sync" be regarded as "part of the language" and not need brackets whereas "sync camera 0" presumably is a "command" and does need brackets. The two seem at face value to do essentially similar things and should have equal status (yes, I know sync does more).

Aren't all commands (or whatever you call them) all part of the language?

No, there's a distinct difference between commands and statements

Statements are things which alter the flow of the program. Such as:

My personal preferences would be as close to DB-Pro as possible.

No, there's a distinct difference between commands and statements

So "statements" have entered the discussion now? Anything else you'd like to mention that's been overlooked? Actually, I thought every line of code was a "statement"? Perhaps not? Who knows? What about sync? Would that now become sync()?

I'm sure there must be a simple rule which tells us which commands, statements, functions, reserved words, etc, etc, would have these superfluous brackets added to them. I'm not convinced that program flow is the defining rule, but it might be. If so then we'll have sync().

OK, simple rule: if it goes and runs some other code then it's a command, and would require brackets to call

Commands are just external functions which are called from DBPro, whereas things like do, loop, etc. do not run any external code, they ARE the code.

As for definitions, every logical line of code (ie. ignoring empty lines, comments, etc.) must be a statement.

The possible statements allowed are defined by the language, but for DBPro include:
- Assignment (a = 1, b = upkey(), etc.)
- Function call (sync, myfunction(), etc.)
- Variable declaration (myvar as integer)
- Flow control (do, loop, if, function, label, etc.)
- Data statement (data)

When I said "statement" I meant the flow control statements and data statements, as that is how they are usually referred to. (The do statement, the while statement, etc.)

I've used the term "Command" to mean functions from a dll in the plugins, plugins-user or plugins-licensed directories, ie. a built in function.

As for the reason behind having brackets around all commands: You have to use brackets when calling a user defined function in DBPro, even when it doesn't return a value. Why should it be any different for built in functions (commands).

I have been a programmer since the early 70's. I started with Fortran and Pascal. Went to COBOL, then to C and ended up with C++ and finally VB. Every programming language as at least these structural components: Variables, Constants, arrays, subroutines, functions and control statements. Every programming language uses a command line. These elements are the basis for a programming language. It seems to me that "statement" and "command" have eventually become interchangeable. For example we can call, "Dim meters as integer" the Dim statement. We can also call "if..then..else" a control statement. This can make it confusing and Green Gandalf makes a good point in wanting to clarify exactly what should have brackets and what should not. Gosubs are also at times called "Gosub statements."

I am not sure how the original authors of such languages as FORTRAN, PASCAL, BASIC and C determined when to use brackets. It seems that one of the rules is that if a function returns a value then it will have brackets. However, this is not always the case. In VB6 there is a DATE function. varDate = DATE. There are no brackets. Then you have a DATE statement with DATE on the right side of the equation. Of course, no brackets here. Then you have arrays. dim varArray(1). Is this a statement or a function? No matter it does have brackets.

The consistency of a programming language has always been confusing to me. I sometimes think I have a handle on it and then my mind goes into a fog once again about it.

So now, should the developer of AppGameKit be consistent with DBPro? It sounds to me that it is more along the line of DBPro than C++. However, if some C++ programmers should be using it, then there has to be some facsimile to the rules of C++ without getting too confusing for the DBPro programmer, I should think.

Should one have brackets on sync. I don't know. There isn't such a command in C++ is there? Maybe there is, although I can't remember.

Although the meanings of statement, etc. have become confused, there is a clear different between a function call, and not a function call.

At a low level, a function call results in a "call" assembly instruction being used, whereas nothing else does. At a higher level, a function call results in some other piece of code being run and then returning, and nothing else does that. IMO, all function calls should use brackets, so that they are all standard. Having brackets makes it obvious that some other bit of code is going to run.

I have been a programmer since the early 70's. I started with Fortran and Pascal.

Looks like Flatlander and I went to the same school (except I did Algol instead of Pascal).

IMO, all function calls should use brackets, so that they are all standard.

I agree.

I'm just not 100% clear what constitutes a function - but if the distinction comes down to whether or not a low level assembly "call" instruction is used then so be it. The distinction is hardly likely to be obvious to the average user. I find it hard to believe that the other constructs don't call code but then I know practically nothing about assembly and machine code.

On balance I vote for brackets - even if it means writing "sync()".

I'm just not 100% clear what constitutes a function

Basically every time you need indention is when you enter into something that isn't a function call, i.e.



In other languages such as C/C++/C#/Java/PHP/etc the distinction is more obvious because you can put braces after all of these such statements, or in python you'd use tabs.

Basically every time you need indention is when you enter into something that isn't a function call, i.e.

What about "end"? [I certainly would indent my code if we had to enclose everything in a begin/end pair, but we don't. ]

Actually, I think Diggsey has made the point about functions quite effectively already.

What about "end"?

End is a function:

I certainly would indent my code if we had to enclose everything in a begin/end pair, but we don't.

We do, if/repeat/while/for/select/case/type/function all have closing pairs that are required.

Actually, I think Diggsey has made the point about functions quite effectively already.

Well you said you weren't 100% sure, so I tried to give a different definition.