After my recent rant on the evils of cut and paste, and some of the feedback I received on this, I have been thinking some more about it, and monitoring my own coding habits.
It was an interesting activity, leading to a sense of needing to repent of my earlier rashness. Cut and paste belong in an IDE, but care needs to be taken in their use.
One particular task I had that required a bit of C+P was i18ning a section of the app. Cut the String out, paste into a properties file, and then whack the lookup code and key back into the file. This task was a big C+P one, that really was aided by some IntelliJ coolness (Clipboard history rocks — <ctrl> <shift> <V>).
As mentioned in one of the comments of my earlier entry, Cut and Paste is also be useful when using an API in a similar way to before, although this often can be a precursor to doing a refactoring. Maybe the automatic insertion of TODO comment would be useful… or maybe not :). (cutting and paste multiple lines to do something is a code smell in need of refactoring).
BUT…. The usefulness of C+P doesn’t negate the risks involved in doing C+P. To keep the codebase clean care needs to be taken… Which is where a tool like PMD is great (thanks Tom). PMD does a great job at finding sections of code that have repeated tokens. It also does a couple of other useful bits of analysis (suggests Integer.toString(int) instead of (new Integer(int)).toString() for instance.
Try running it across your project and see what you find ;).
At least every time they are used in combination a big alert should pop-up listing the other available refactorings, with a random chain of “Are You Sure” dialogs popping up if the developer trys to continue.
Cut and Paste are the source of way to many AntiPatterns
I just had a page hit the max size that WebSphere can handle.
I was preparing myself for pain in splitting the page into sections, carefully making sure that I matched tags… but to my happy surprise, but found that the job was almost too easy with IntelliJ.
I just went to the start tag, and IntelliJ marked for me the code that went to the end tag. A quick cut and paste, put in some includes, and wow, it all works.
And doing jsp editing isn’t even one of the great strengths of the IDE.
It sure does make development a pleasure ;).
Everyone needs a spell checker for their browser (especially people blogging)….
and since most people use IE, that works.
My prime area of Java development experience has been building Business J2EE applications. The standard N-Tier Web-based client write stuff to a database app with a spot of workflow thrown in.
I have recently had opportunity to write an application that runs in the same architecture but will be deployed to the desktop (Windows only initially), with all the problems that this brings with it….
The good news is that “all the problems this brings with it” is a really small number of problems in reality. The license of the JRE means that I can package it up and deploy it. Jetty will install and run beautifully, and with Google I found this great little Free Windows Installer. It all plugs together seamlessly for a professional looking install.
Microsoft and Sun are planning the future in programming languages.
Microsoft has got F#
and Sun has got their ACE, and of course there is AOP.
Some interesting looking stuff for the future….
Just saw this up on JavaBlogs.
The scary thing is the number of people who check in code at Level 1 :(….
The next scary bit is how easy it is to think that you have something at a level 5, when really it didn’t reach two….
How do you go about improving that.
I guess the XP answer is continuous integration with a really awesome build server.
Anyone got good answers?
Over on Artima, some guy is asking Which Language When?, and looking for unbiased language gurus. I think the problem that he will find is that most people who rate as “language geeks” are also going to have a disposition to a particular language for one reason or another.
I just went and collected some of the better places for thinking about programming languages.
The Pragmatic Programmers are pretty good, but would have a bit of a bias towards Ruby(maybe because Ruby Rocks ;)). Paul Graham has some good insights, but has his own biases, as does Bertrand Meyer. Guy Steele would also rate as having at least a pretty good understanding of some of the more well known languages.
Another decent place is Artima.com itself, and Bruce Eckel has a decent idea of Java and Python.
Languages are too much like Editors. It is too much fun to start wars for people to be totally unbiased ;)…. and alot of the experts seem to like making their own.
I have been reading the classic Object-Oriented Software Construction by Bertrand Meyer. He talks about abstracting the implementation details, in particular hiding wether a feature of a class is stored or computed at run time, and then goes into the syntax for doing this in Eiffel, the language that the book points people towards.
Eiffel has the concept of a no-args function being accessed in a similar way to a attribute, so that clients cannot tell the difference, making it possible to transparently replace functions with attributes.
I had a bit of a think about how Java does it, and the obvious answer is JavaBeans. ie lots of getX and setX style methods on a class that have single lines that do the get or set. (<ctrl>-ins in IntelliJ).
So the Java way is always to make things look like method calls. Betrand raises some good points about how to hide things, and I think that Eiffel looks pretty good. It is does more in the language to make it easier to write things than in Java. ie in Java you have to do things by best practices, and it doesn’t make things as easy natively. But then IntelliJ makes best practices shortcuts so — meeting their “Develop with pleasure” tagline.
Ruby does it differently to either language. In Ruby you create a method called attribute= for assignment, and the compiler does the magic to treat it like straight assignment (see Programming Ruby for more). Of course Ruby rocks ;). Lots of nice bits of syntactic sugar and good stuff.