This is one of Java's biggest problems: people write tools instead of libraries. Getting the path to the Desktop should be achieved in some way other than hardcoding the word "Desktop" and the path separator in your application code; it should be a method on some generic "desktop environment configuration" object that's passed into the class that needs it.
There are a number of big problems with autogenerated code. One is that if you change your "how to get the path to the Desktop" algorithm, you have to manually change it in every place. This is hard to get right, so now your program is buggy and you have no way of knowing that you ever fixed it. Another problem is that the hard-coded solution is intrinsically inflexible; if the programmer had delegated to some other object, configuration could be passed into the class. It's not the "move all files out of this directory" class' job to know the details of where Windows, GNOME, KDE, and OS X keep the desktop!
One other nitpick is the flaky snippet that makes the for loop. Typing "for (File file : files) {" takes almost no time. But the snippet names the loop variable wrong ("elem"?), and correcting this takes more time than manually typing it correctly the first time. If you're going to be smart, be smart; look up the un-pluarlization in a dictionary and choose that. But don't choose a super-generic variable name, because now you've made the code of everyone that uses this tool less readable.
All in all, people seem to love shit like this, but it encourages horrible programming practices. Making it easy to write long, linear pieces of code is not a good thing. I think the opposite is what we really need: make it harder to type so that you spend more time thinking and creating a design that requires less code!
If you don't know how to access the "desktop environment configuration" object, how do you find it?
Snippet search integrated into the IDE is very useful. Yes, the snippets in the video aren't perfect. That isn't a big deal - those snippets will be modified/replaced.
My point is that you shouldn't need snippets; where you would use a snippet, write a library instead. Adding code to your application is the worst possible thing you can do when programming. Don't use tools that make this easy.
"Programmers would still need to search for methods to call.
You can use CodeMatch to write snippets that call methods and CodeMatch can also auto-import libraries (or insert the classes/methods inline)."
There are a number of big problems with autogenerated code. One is that if you change your "how to get the path to the Desktop" algorithm, you have to manually change it in every place. This is hard to get right, so now your program is buggy and you have no way of knowing that you ever fixed it. Another problem is that the hard-coded solution is intrinsically inflexible; if the programmer had delegated to some other object, configuration could be passed into the class. It's not the "move all files out of this directory" class' job to know the details of where Windows, GNOME, KDE, and OS X keep the desktop!
One other nitpick is the flaky snippet that makes the for loop. Typing "for (File file : files) {" takes almost no time. But the snippet names the loop variable wrong ("elem"?), and correcting this takes more time than manually typing it correctly the first time. If you're going to be smart, be smart; look up the un-pluarlization in a dictionary and choose that. But don't choose a super-generic variable name, because now you've made the code of everyone that uses this tool less readable.
All in all, people seem to love shit like this, but it encourages horrible programming practices. Making it easy to write long, linear pieces of code is not a good thing. I think the opposite is what we really need: make it harder to type so that you spend more time thinking and creating a design that requires less code!