I think there is just some semantic confusion here. I think a "best practice" should be a practice that is good to apply across a certain problem domain (regar

I think there is just some semantic confusion here. I think a "best practice" should be a practice that is good to apply across a certain problem domain (regardless of where you work or what dev team you are part of). And there are coding styles/guidelines which can apply only to a specific dev group or codebase. They can often be arbitrary, in the sense where it would be fine to do it in different ways, but one is chosen, for consistency (to promote maintainability/readability). They can be one way to achieve a best practice. Day to day, it's probably fine to loosely call all these "best practices" since you apply them the same. But it is also sometimes useful to make the distinction, e..g, so you understand why a certain practice is being used. The first example is a coding style, and a judgement call. The underlying "best practice" is to separate interface from implementation. There are various other ways to do that, of course, and need not be done like this. (Personally, I find this practice a little "enterprise-y", which I consider an insult.) The example about version control also depends on the process and practice of the dev group.