Quoting Krzysztof Kosinski <tweenk.pl@...400...>:
2010/7/17 Josh Andler <scislac@...400...>:
Is new code being added that is prefixed with sp?
I think it's OK to keep the sp_ prefix when adding functions to existing code for the sake of consistency.
Not really, at least not for new functions.
We've gone over this as a project a few times. First of all, we have an overall desire to get rid of the "Sodipodi" naming.
More importantly, though, is that we should not be targeting long bare C-style decorated names. We need to favor class static and member functions over bare C functions.
We also need to favor namespaces over extending c-style names. And favor classes over namespaces.
If we have existing *code* with existing names with "sp_" as a prefix, then for branches it might be beneficial to leave those existing names as-is. However, this would only be for the sake of reducing diffs and merge conflicts.
New functions should avoid the "sp_" prefix.
And finally keep in mind what Emerson said, "A foolish consistency is the hobgoblin of little minds".
For example, if one were to add a function to perform "foo" on SPStyle, instead of creating a function named
void sp_style_perform_foo(SPStyle *style, ...)
one should instead add a *method* to the SPStyle class itself as
void SPStyle::performFoo(...)
And of course if a function is not directly applicable to a specific class, it should be considered for a static method on a pertinent helper class. (But here we wonder off into the abstracts of OO design.)