Naming Conventions and formatting?


Am I right to say that:

Globals begin with a capital letter?
Locals begin with a lowercase letter and remain lowercase?
Custom Object Variables begin with a lowercase letter, but each new word begins with a capital letter?
Scripts are all lower case and each word is separated by an underscore?
Enums begin with a capital letter?
No, there're many different standards and you can make your own up. Unless you're specifically working under someone who has laid out a standard guide for the work you are doing, the only thing of any importance is to keep your style consistent.

I have no changes between globals and normal variables, the global. in front of globals already indicates which is which. I prefix local variables with an underscore, apart from that they follow the same naming convention as my other variables. I prefer snake-case, so I use that for my variable naming style. I capitalise the first letter of each word in functions and my enums are in all caps, as an example.


Friendly Tyrant
Forum Staff
Yup, as stated above, there is no set standard, and when working for yourself then you should use whatever makes you feel comfortable. the MOST important thing here is that you are consistent in your application of any syntax rules you apply... In the long run it'll make re-reading and understanding your code a LOT easier. For example, for me it's generally:

Globals always start with a capital and use camel case: global.SaveMap
General vars (and functions) are lowercase and use snake case: my_general_var = "foo";
Local vars are always prepended by an underscore: var _this_var = "bar";
Enums are always all caps: STATE.MYHP



I have but a few naming conventions. All resources are lowercase snakecase, like obj_some_controller, spr_player_walk_left, shd_blur. All variables are Camelcase snakecase: State_Variable, Large_Enumerator.Third_Option, This_Is_Struct.Method_Get(), global.UI_Controller. Locals get an extra snake at the beginning: _Local_Variable, function Method(_First, _Second){ ... }. I'm also doing this for some structs whose only purpose is to help constructing other structs. For example in my UI system I long ago passed the 16 argument limit constructors have. I'm now grouping data to logical struct groups and bring them in. So, my UIElement_Base constructor accepts positional data (x, y, width, height, stretch type, context) that is brought in through a helper struct _UI_Pos.


Naming conventions and rules of any combination are generally all okay, as long as they're well documented, communicated and used consistently.
Oh and please make sure they don't trigger any of your teammates' obsessive-compulsive disorder.