Question: What is the difference between WordPress_AbstractFunctionRestrictionsSniff and Generic_Sniffs_PHP_ForbiddenFunctionsSniff?

[grappler]

I am looking to create a few extra sniffs and was not sure which to use as a base.

There is also Generic_Sniffs_PHP_DeprecatedFunctionsSniff which extends Generic_Sniffs_PHP_ForbiddenFunctionsSniff

[jrfnl]

My two pennies:

Generic_Sniffs_PHP_ForbiddenFunctionsSniff is a great one to extend if you simply want to forbid a number of functions and mention their potential replacement. It can use regex patterns as well for matching function names. However the error message is not very flexible, so you can't change it.

The Generic_Sniffs_PHP_DeprecatedFunctionsSniff should not be used as the basis for extending. It uses Reflection to check for deprecation on native PHP functions. AFAICS, this will not work for non-native PHP functions. It also does not provide info on what a potential replacement could be.

WordPress_AbstractFunctionRestrictionsSniff allows for a more modular approach, providing groups of functions and people can use the sniff, but still disable one (or more) of the groups for a project.
It offers wildcard matching, but not pattern matching. And if #626 will be merged, you can selectively whitelist functions which would match the wildcard.

All of these currently suffer from #611 - they don't check in callbacks. I would guess that that will only be solved for the abstract and as WP uses callbacks a lot, that would probably be the safest choice looking to the future.

[grappler]

Thanks, that answers my question.