The current style guide may be found here: http://haxeflixel.com/documentation/code-style/
While I know it would be difficult to change certain conventions, I want to put forward some arguments and suggestions for consideration.
As well as having intrinsic benefits, some style changes could help to make HaxeFlixel more appealing to prospective developers. On a couple of occasions I've spoken to developers who do not use Flixel, but did cite the strange prefix naming convention.
The "Flx" Prefix
Regarding the Flx prefix, the existing code-style doc points out, "Even though this is widely regarded as bad style, it still makes sense to follow this convention since it is so deeply ingrained into the flixel workflow and doing otherwise would be very inconsistent and confusing."
Arguments for changing this convention include:-
- The prefix is unnecessary. Packages already provide this information and should be used to resolve name conflicts.
- Increase readability. Shorter lines, less fluff.
- Less to type.
- Better for auto-completion.
- Yes, it is considered bad style, and this might affect prospective developers' likelihood of trying HaxeFlixel.
Arguments for keeping the convention (with counter points):-
- "It's always been that way and I'm used to it."
- Prospective developers are not, and it is in your interest that HaxeFlixel remain competitive with alternatives to ensure there is active interest in continuing development. The more people using HaxeFlixel, the more contributions it will recieve. Some developers might compare HaxeFlixel to an alternative and think "HaxeFlixel and X are both good, but HaxeFlixel has an ugly, impractical naming convention. I wonder what else in HaxeFlixel is ugly and unconventional. I'll go with X."
- The "I'm used to it" argument can be applied to every bad design/convention ever.
- It is easy to become used to a better, cleaner design.
- A lot of work to change?
- The work is heavily reduced by automatic renaming, i.e. Refactor->Rename, or find and replace in files
- Changes the API, migration impact for users
- Considering the next release will be a new major version, now would be as good a time to change it if ever.
- Could provide migration script?
- ~~Could provide option to restore the old names with a flag in project xml, which uses typedefs?~~
- It lets you see which classes belong to the engine.
- Why should this be useful? When using a class one needs to know its function, not where it came from. Far more information can be gained by hovering the cursor over a the text in FlashDevelop.
"_" prefix for private variables
The underscore prefix is a remnant of AS3, which required underscores due to a deficiency that Haxe does not have. The underscore convention is generally useful in languages that allow you to define getters and setters of properties, but where a naming collision might occur between the getter/setter methods and the member variable. Haxe does not have this issue, thanks to the way properties are defined. Note that changing this convention would not affect the API.
Arguments for changing the convention:-
- The underscore is no longer required.
- It is more robust. When using an underscore, any decision to change the visibility of the property would require a complete rename, whereas without an underscore you simply need to change the property signature.
Arguments for keeping the convention:-
- It let's you easily see which variables are private.
- This should not be useful. It is much better to consider the implementation of methods separately to the public interface.
Captitalized method parameters
This is pretty unconventional. It makes local variables look like classes, especially when they share a name with a class. It is futile simply trying to avoid the "this" keyword, as there are places it simply cannot be avoided, such as when using abstract values. A find and replace in files with some simple regexs could probably make this less tricky to change. The API itself would not change.