Why camelCase?

[radicaled]

I was about to start writing my own visual UI for my game's FSM when I noticed this addon had been radically changed and now looks more or less like what I was going to do, so it's saved me quite a bit of work. :)

However, I was wondering why everything uses CamelCase instead of snake_case like Godot uses -- is this just preference or does it affect something under the hood?

[kubecz3k]

Sorry it's just a preference, this is code convention which we are using in our projects. I can definitely change api for part that's exposed for users, but I'm worrying about backward compatibility (even we have quite a lot of projects that are using this plugin already). So I don't think this will happens until some major compatibility breaking changes will be needed anyway. That's unless people will really request this :)
(in fact it's a lot less work on the plugin side than on the side of projects which are already using the plugin).

[kubecz3k]

I don't really know how to gain feedback on this, have no idea if my plugin is used by three people or more, and if it would be potentially harmful for anyone if I will just change the api right now, but I think I might give it a shot.

[radicaled]

There's no pressure from me to change it -- I was just wondering the reason why, since I keep trying to type the snake_case version out of habit. I'll resolve that little problem locally by aliasing stuff like logicRoot to logic_root = logicRoot under the hood and all will be well. I suppose if you wanted to change it but keep backward compatibility you could do the same.

[kubecz3k]

There is addons/net.kivano.fsm/content/StateTemplate and TransitionTemplate files which you can modify to have different default template for states and transitions. Just remember to copy your templates somewhere, because those files should be overwritten on plugin update time.

[LLafodog]

Just to say, as I use your addon a lot, the camel case is indeed weird; as the whole godot API is in snake_case. I guess everyone using godot tries to use snake_case for consistence with the godot API; and so maybe using the convention may be a good idea.
On the other hand, the FSM structure usually locks all the code it requires (logicRoot etc) in its state and transition; making the dissonance not really visible from outside the FSM nodes; so it is not a major issue in my opinion.