So what is fake code? That, I can at least try to explain in a bit more detail.
The other day, I saw this image posted on Kris Rice's twitter feed:
I thought it was a joke, but it's actually a real book. That made me laugh. Then cry. Then I read the book, mainly since it's only 4 pages. Believe it or not, there's actually some really good content packed in there. Let me summarize:
If you choose to copy code from Stack Overflow, the OTN forum, or anywhere, really, there's a few things to keep in mind:
- Who owns the code. It's more than likely perfectly legal to copy and use the code you find on these sites "as is", but keep in mind there may be exceptions to this rule. The first page in the booklet offers some insight as to what they are.
- Who gets credit for the code. While not required, it's a good idea to credit the author of the snippet that you used. This is not just courteous, but also provides a reference back to the source of the code, so when it breaks, you know where to start looking. Which brings me to the third and most important thing to consider:
- How good is the code. Unfortunately, there is no easy way to verify this. You can look at the number of up votes for a specific response, but even that can be easily faked - or more likely, just be wrong because it is based on an older version.
The first two issues don't concern me all that much, as the first is rarely an issue and the second is simple to solve. The third however, does concern me a lot. FAKE code - where FAKE stands for Found Another Killer Example (yes, I made that up) - is fast becoming the way that we develop solutions. Simply enter in some string of what you're trying to do into Google, and a set of possible solutions will magically appear on the page.
With very little effort, you can copy & paste that snippet into your application, run it, and if it works, then you're job is done and you're a hero. If it doesn't, some more searching and some more tinkering is in order. Maybe it's a 15 minute task instead of a 5 minute one. But that doesn't matter, as what you were asked to do is done, and you can move on to the next problem.
There's definitely some problems with this approach. If you don't understand what the code is doing, who is going to fix it when it breaks? And it will break at some point. As other libraries or components get upgraded and/or browser versions change, code will eventually break - usually at the worst possible time.
If you get lucky, and it doesn't break, then who is going to change how it works when the users come up with new requirements? If you don't have a full grasp as to what it does or how it does it, then you'll have little success in changing how it works.
And just because there's a solution, does it mean that is the best, most secure, most performant solution? It may work fine for a single user on a development environment, but what happens when its implemented in the real world? This is especially a concern when you're implementing something in a language that you're not as proficient in, as you won't be able to readily spot bad practices.
In no way am I saying that any of these sites are bad, nor saying don't use them. I use them all of the time to find solutions to problems and contribute solutions, as do many others. They are all a valuable resource that makes our jobs a lot easier to do.
What I do want to emphasize is that when you do use any site that presents a solution or code snippet, be sure to not only vet the solution, but also ensure that you completely understand how it works, and be ready to fix it if it breaks. If you can't do either of these things easily, then perhaps its best to find an alternate solution to your problem - one that you can understand and maintain
FAKE code is a real danger to any development project. Sprinkle enough of it around, and you're essentially creating a ticking time bomb, that's just waiting to explode. But FAKE code can be spotted and stopped fairly easily: Document the source of any snippet or blog you use. Take the time to learn what it does line-by-line, and document that, too. Be ready to support it if in the case it breaks. And if you're not comfortable doing so, have alternative resources lined up or at least identified.
Together, with a little bit of work, we can stop the FAKEcode epidemic.