We're looking for some feedback with regards to the command structure within App Game Kit (for the scripting side). Currently we're leaning towards something like this:



It's very similar to the existing structure of DB Pro commands, with the difference being no spacing in the command names. The alternative is more like a DB Pro command with a space being used:



AGK has been written to cope with either method, but it's better to pick one to avoid confusion. What are your thoughts on this? Do you prefer no spacing or spacing in commands?

No spacing just nice and consistent camel case. Pleeease no spacing, or maybe make it optional?

Please NO SPACING!!!!

My personal preference would be for spacing

Can I also ask for a bit more consistency with naming conventions than DBP has please?
For example:

Might be better as:


Obviously these are 3D and not relevant to the App Game Kit but you get the idea

Consistency of commands is something we have been discussing. We're going through the list making sure it's much better this time round.

Spacing would be nice. Makes for easier reading. Granted some people can adjust to reading non-spaced commands over time but I'm one of those that can't. So spacing would be appreciated it.

Personally, coming from a c# / c++ development back into a BASIC style development, I would prefer the commands to be as in the first example.

No spacing and brackets if you ask me. After a while people will use alot of their own functions (which have brackets) anyway.



or am I going the wrong way here? o.o

Having done a couple of things in DBPro recently after coming from a C++ background there is one thing I find a little confusing, you can end up with commands looking like this:



Its not apparent at first glance what is going on, I think no spacing would help with this problem. One step further would be to always use brackets for command parameters but that may be another issue.

EDIT: OK, link beat me to it in the post above.

Just Poppin in and making sure I get this app...

I would say no spaces, even tough I am used to spaces.

Have an overly large number of commands that all do the same just to make sure everyone can use it !

Have:

You can't go wrong ! - And everyone's code, even if they copy other people's projects exactly will still likely be different.

After seeing this:


I have decided to change my vote to NO spaces.

I'd prefer something like functions are in C (no spaces, always bracketed, and returning either a type or 'void'), but with case-insensitivity.

The problem with case-sensitive names is getting the case right - is it rgb, Rgb, or RGB?

Having no spaces, makes it easier to write tools that understand the code, and standardisation on brackets makes that even easier.

matty, the line of code you showed is the main reason why I dislike spaces.

I agree with matty halewood's reason for NO SPACES. It took me a long time when I was learning DBPro (and even now on occasion) to realize that two commands were involved in statements like his example.

Can we make them case sensitive as well so that you must use things like LoadImage (or loadImage) rather than LOADIMAGE or loadimage. It makes a big difference to the readability of some long commands.

[I'm glad Scraggle now agrees with the NO SPACES position. I was beginning to doubt his sanity. ]

Edit (to IanM)

The problem with case-sensitive names is getting the case right - is it rgb, Rgb, or RGB?

Why is that a problem? The same principle applies. The first letter of each word should be capitalised - and RGB is an abbreviation of course.

Although I'm unlikely to use this I also hate spaces in dbpro's commands. Definitely camelCase, and like GG said uppercase commands are less readable. (Just as any text in uppercase) The IDE could auto-correct the case whatever the user types if it's purely for readability.

Can we make them case sensitive as well so that you must use things like LoadImage (or loadImage) rather than LOADIMAGE or loadimage. It makes a big difference to the readability of some long commands.

This is best done at source level through the IDE.

@GG,
In English, it's wrong to do so, but when coding, quite a few professional programmers take abbreviations and capitalise the first letter only, simply because it makes the names easier to read when you have no spaces separating words (which seems to be a common consensus here).

Not too much difference in readability here:
ConvertKMToMiles
ConvertKmToMiles

Big difference here:
RGBToHSV
RgbToHsv

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

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

Unless the programmer could choose their preference and the IDE auto-corrected it, best of both worlds