Class name consistency

[brianvanderburg2]

There is inconsistency in many class names and file names, whether or not underscores are used, case, etc.

• cMovingSprite
• cMoving_Platform
• cImageSet
• etc

I personally don't see why underscores are used when CamelCase is being used but at some point it would be ideal to pick and and adapt the rest for consistency. Maybe a policy should be defined for nested/related structures as well:

*cImageSet uses cImageSet::FrameInfo, cImageSet::Parser, cImageSet::Surface (nested, no prefix, still using CamelCase)

• cMovingSprite uses Moving_state (not nested, doesn't begin with "c", uses underscore but related main class does not, second word not uppercase, ideally should be cMovingSprite::State or cMovingState or something
• cMoving_Platform uses Moving_Platform_Type, Moving_Platform_State (not nested, doesn't begin with "c", uses Camel_Case (with underscore)

I would say that nested structures should not use the "c" prefix or class name. Unnested structures should, but should still follow CamelCase, and not use underscores. I prefer nested when possible

Nested:

• cSomeObject::Data
• cSomeOtherObject::PositionInfo

Not Nested:

• cSomeObjectData
• cSomeOtherObjectPositionInfo (yuck)

[Luiji]

The inconsistencies result in the age of the code base and the transition from SMC coding styles to TSC coding styles. Personally I agree with you in all regards, except that I don't think any class should use the c prefix (though I won't start up a vote on it -- simply not worth it).

I'd wait to correct these things until the branches get in a more stable state (e.g. there are less of them in use) so that we don't have to work with merge conflicts.

[datahead8888]

I don't think any class should use the c prefix

I agree. Prefixing everything with c seems funky. I think we could just use CamelCase for everything (nested or unnested). If we need them to be different we could make nonnested classes start with a capital letter and nested not start with a capital letter (ie. NonNestedClass and nestedClass). @Quintus, what do you think?

I'd wait to correct these things until the branches get in a more stable state

Yes, we might wait until the SFML port is done before renaming classes across the entire application.

[Quintus]

I think you are right. The “c” prefix has its origins in the old SMC code base, and it was superflous already there due to the underscores. During my work with the old SMC codebase I came to the conclusion the “c” was used to mark real C++ classes, whereas it was left out for old plain C-style structs. Since I took up development it got probably more inconsistent.

Also, some classes use underscores and others don’t. I’ve not yet found out a rule this follows.

Therefore, I think I agree with Luiji when he suggets to drop the “c” prefix altogether and just use CamelCase for class names, and I add for C structs just alike. We don’t have to differenciate between the two.

For the timing, I think we should wait with these changes until the SFML port is finished. Branches are to divergent currently to apply such a mass-transformation on them again.

Valete, Quintus