My theory is that we focus too much on the final points of "best practice advice" and very little on the reasoning behind it.

As programmers, we need to start demanding that logical explanations always accompany best practices or dismiss them as bullshit.

I tried this for over two years at a job, which inevitably resulted in "well, John has 25 years of experience, and you have 5".

You might be able to reframe it as a "why" question. Then you're no longer questioning the experience, but the ability to impart that knowledge to others.

When someone quotes something as a "best practice" I usually take it that they aren't actually interested in the "why" and probably have no idea of what the underlying justification is.

What's wrong with quoting best practice and pointing the why in your framework of choice documentation that explains the best practice and the why?

Functions are evil in some languages (C++, Java) because they can't be overridden or customized with virtual methods. In functional languages that don't need polymorphism as much, it's because you can accomplish similar effect with heavy use of higher order functions, which is something that is impractical to do in many OO languages. Functional languages also have their own set of rough edges, FP langauges force an OO programmer to look at a lot of concepts (objects, polymorphism, mutability, encapsulation) in a new light, as they are applied quite differently when you start leaning on functions so heavily. I think if one is in an OO language like Java and starts using static methods everywhere, you end up in a half-way danger zone which can be extremely painful down the road.

Anyway, beware challenging conventional wisdom, it evolved due to past pain and gets passed down generations to avoid that pain, even if the reason is not well understood anymore.

For the 'best practice' to work, you'd have to make your object accept an interface, in order to be able to accept one with the overridden function that you want, correct?

I think this is the problem with the received-but-not-understood wisdom -- the implementers don't actually use an interface but hard-code the class that has the method, so it's not any more over-rideable than a regular function call.

Funny anecdote: I was recently contracting at a company that was OOP gone amuck. Everything written in Java ca. 2001 style. Lot's of message wrapping and unwrapping. Lots of dependency injection fun and games.

At some point, their lead developer tells me about some guy they had for a job interview a while back, and as the story goes they had him through a code review where he was berated for using a static helper class. Apparently his reply was something like "You're using static classes for view helpers? But that's insane!". The morale of the story as told, was that clearly he didn't know right from wrong and was passed over. I didn't know what to reply to that.

"Java ca. 2001 style" also seemed to include using every feature of J2EE even if it wasn't remotely relevant.

Crazy files of constants seemed to feature a lot as well:

   public final static string HTTP = "HTTP";
   public final static string COLON = ":";
   public final static string SLASH = "/";

and then the inevitable:

   string url = HTTP + COLON + SLASH + SLASH....;

[I did think about posting it to the DailyWTF at the time but thought that might be bad form when you are the lone contractor trying to rescue the project.]

Once, I was using a struct for some simple data. I added a very simple member function to sanely format the data. I thought I was going to be hung in the code review for not using a "proper" class.

Now you just need to reintroduce the original function, and call it a performance and memory "optimization", because you no longer have a singleton or its construction to worry about....

We will probably get "uniform call syntax" with C++17. So methods can be called with free function syntax and vice versa. They really are the same.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n447...

Singleton? No no, those are ALSO evil. No, we need to use a dependency injection container to provide that object instance.

It reasons like this Uncle Bob pisses me off.

Functions with closures are as powerful as OOP and can be used analogously.

Also, singletons aren't portable.