Definitely no spaces! Aside from the readability problems, spaces in commands is the cause of about 50% of the bugs in DBPro IDEs

Also, always have brackets, like IanM said. (Again, for both readability, and IDE support)

Case sensitivity is a tricky one, but I'd say to go case sensitive, but with autocomplete in the IDE which will find the command regardless of case, like in VC++ (so it actually requires you to press tab to fix the case rather than doing it automatically. Automatically would be very annoying).

It would be nice to get some guidelines for naming conventions, programming style, etc. for user code as well, so that everyone who follows the guidelines will have consistent code.

Finally, this is unrelated, but PLEASE make it so that each source file compiles to its own object file before they are linked! It would improve compile times for large projects dramatically.

No spaces please. After dabbling in C++ it just makes sense!

Same with brackets. That'd make things a little easier. I'm also not sure on case sensitivity, but I definitely like the looks of commands looking like this:



Now that I re-read that, it reminds me of BlitzBasic...which brings me to another thing....

If AppGameKit does eventually go 3D (or does it already?), do we HAVE to assign 3D objects and images numbers? Or will there be a different way to reference them? Just wonderin'.

My vote is definitly for:

- No spaces
- Allways brackets
- Case-sensitive

No spaces and always bracket's, that's what i vote for

- No spaces
- Always brackets around parameters
- Case-sensitive
- Case-Corrected

Much cleaner looking code in my opinion. Feels more programmy like
Would be splendid

@Ian

So you'd go with case-corrected, taking it out of the programmers hands?

I don't understand the question ?

No spaces.
As far as brackets, either

brackets if it is a function that returns a value. No brackets if it is a subroutine that does not return a value.

OR

brackets always.

Prefer former; but can cope with latter.

As far as upper/lower case. I like a combination when there are no spaces. I also like the IDE's of other languages that will auto correct. That way I can just type all lower case and then it will be corrected. This also is valuable to determine if the command verbiage is spelled correctly. I also like to create my own variables with a combination of upper and lower case and it too be auto corrected.

All-in-all, whatever the decision, one will need to just simply get used to it.

Case-Corrected

I second this, after using C++ and C# having grouping symbols and non-spaced, case sensitive commands makes the readibilty easier and it is easier to trace through the code to find user made coding errors.

Case-Corrected

Agree.

@Kevin,

don't understand the question ?

Simply that no matter what the programmer types, that the IDE will automatically parse the line and correct all case of commands/functions/variables etc when he/she hits the enter key or moves from the line in some way.

Returning to the abbreviations issue, I find the correct versions of your examples easier to read, i.e.

ConvertKmToMiles (since kilometre is one word)

and

RGBToHSV (but I agree the RGBT bit looks awkward - why not RGB2HSV?).

I don't like the idea of autocomplete/autocorrection. I find it confusing to have something other than what I want flashed up in front of me while typing. But that's probably a very personal view.

However both these issues are minor and I agree with Flatlander's comment: "All-in-all, whatever the decision, one will need to just simply get used to it."

But, please, no spaces.

Case-Corrected

I agree, except I don't think it should need to be case sensitive.

@Ian,

Simply that no matter what the programmer types, that the IDE will automatically parse the line and correct all case of commands/functions/variables etc when he/she hits the enter key or moves from the line in some way.

If the back end are to be case sensitive, then it makes more sense for the IDE to 'assist' programmers as much as possible (case correction, auto completion).

If it's not case sensitive, then the user/IDE could tweak the style however they please. It's irrelevant.

No spaces, or I guess you could optionally use _ to keep it one "word", Brackets, and consistency is really important. I don't really care for case-sensitivity, just makes it more work to code.

I say:
Spaces for faster typing (and my personal preference).
Brackets for easy identification of when a command ends and the arguments start.
Auto correction for case sensitivity.
Auto completion for faster command typing (Checkbox to turn it on and off).
Spell check for misspelled commands.

Wah, lots of discussioning!

I agree that spaces in the middle of commands are ugly and difficult to follow. I'd even take it further and suggest that instead of set object wireframe obj,1 we'd write the same thing like this obj.wireframe = 1.
So objects are a type, I feel like DB is progressing towards this kind of syntax anyway. This works nicely because we can think of the wireframe property of the object in the same way as a variable.

This is sort of the same argument as changing let x=1 to x=1

Oh and while we're at it please have a different symbol for assignment and comparison operations, using "=" for both is always confusing.

I'd love to see some sort of code block implementation, what I mean is like in C where everything between {} is considered part of the same block to be executed. This could also solve the problems that sometimes crop up because DB has no end-of-line symbol, if we could use blocks we could string lines together and still avoid using an end-of-line symbol. eg

"

Personally I believe that the closer you keep it to original DBpro commands, the better people will be able to swing into it.

Personally I believe that the closer you keep it to original DBpro commands, the better people will be able to swing into it.

Yeah, that's my thought aswell. The spacing or non-spacing is more a personal preference, so maybe make 'em both possible. Just don't make this into a language that has to be learned from the ground up.

Cheers

Hmm, I like using the types. Something like texturing and object could be like this:

object.texture(object, texture)

Or you could set it up like a C style language and use the namespace "object".
object::texture(object, texture);

Although it probaly wouldn't be a good idea to use namespaces for multiple reasons

- No spaces within commands
- Always brackets around command parameters
- Case-insensitive commands