Why prefixes in the first place?
The prefix for function names is a C practice that intends to avoid naming conflicts.
This is especially suitable in big projects, where different teams could easily come with
do_that() in different subcomponents of a large codebase.
Since C lacks of a
namespace or a
package feature, the prefix is the most common workaround. It’s not the only workaround: There are other approaches , but with their own drawbacks.
Does it make sense for static functions?
Of course, prefixing internal static functions does not reduce any naming conflict. This is a side effect of the prefix scheme decided in the first place.
The reasons that justifies this practice are:
- consistency in the naming scheme: if 80% of the time you use a prefix, not having it on the 20% remaining functions might cause more confusion than you’d expect.
- flexibility in the evolution: bear in mind that all
static functions were not necessarily static from their inception.
static or not
static is something that could change over time. And mixing prefixed and unprefixed name could make such natural changes more painful than necessary.