This is really about naming. Never name anything “smartXXX,” “fastYYY,” or “safeZZZ.” I see it happen all the time.
The crux of the biscuit is that once you’ve called a function, method, class, or what-have-you “smartXXX,” “fastYYY,” or “safeZZZ,” why the hell would I ever use ordinary XXX, YYY, or ZZZ. Am I supposed to prefer “dumb,” “slow,” or “dangerous” code? If the version you’ve produced is purely superior and functionally equivalent to the existing code otherwise, get rid of the existing stuff. If it differs in some meaningful way, it can’t ONLY be that it differs in being smarter, faster, or safer. Otherwise, you’d purge the other one. Tell us something useful in its name about why the old one continues to exist. If your new one is “safe” because it catches exceptions and deals with them somehow where the old one allowed them to pass upward, don’t call it “safeFoo,” call it “FooNoThrow.”
Consider developer Goofus:
Goofus is looking at a function that crabulates fribs. It is called “crabulate.” He’s a pretty smart guy and he realizes that in most cases the fribs he’ll be passing in are already sorted. That means that the first step of crabulate is already done, and since he’ll be calling it a lot, he wants to save the time of the re-sort. Now he’s too smart to just add a boolean parameter to the signature of crabulate that causes it to skip the sort. (That’s a separate essay, that I’ve intended to write for a while.) And he doesn’t really know if anybody else is already using crabulate with unsorted fribs, so he can’t just yank the sort out. Instead, he factors the crabulation into two parts, the first does the sort, and then calls the second new function which does the rest of the crabulation. Goofus calls this new function “fastCrabulate” because it’s whole point is that it can crabulate faster. Now Gallant comes along and he wants to crabulate too. His fribs are a mess. How does he know not to use “fastCrabulate?” Goofus left him a stinking comment in the header that told him what to watch out for. Comments are to good names as gold leaf is to solid gold. Come on, Goofus. Gallant renames “fastCrabulate,” to “crabulatePreSorted.” Thanks, Gallant.
And don’t get me started on “smart.” Anything that has to tell you it’s smart should be given a cookie and sent home. I’ll tell you if your function is smart.
What’s that I hear you saying? You want to know what’s so bad about “quickSort,” “fast Fourier transform,” and “smart pointers?” They’re all crappy names that don’t tell me anything about what makes them good beyond that their mother loves them. Take “quickSort.” Tell me how it works. Did the “quick” part help? How about “bubbleSort,” “heapSort,” “insertionSort,” “radixSort.” Oh, yeah. Those tell me something. Damn you quickSort! “pivotSort” would have been way better. “quickSort” sounds like it came out of a marketing meeting. “Fast Fourier transform?” Same deal.
Now “smart pointers.” That’s a really bad name. Smart how? Are “raw” pointers “dumb?” I’ve seen good and plenty dumb uses of smart pointers. Generally smart pointers are mostly talking about resource-tracking and RAII. Why not something like “resource pointers” or “tracked pointers?” What mitigates this one slightly is that almost nobody just flat out calls their smart pointer implementation “smartPointer.” Boost does the right thing and offers, shared_ptr, scoped_ptr, weak_ptr, etc. Alright. Those have meaning. At least “smart pointer” is referring to a class of ideas instead of a particular algorithm or piece of code. As long as “smart” doesn’t creep into the actual code, you’re “safe.”