Some thoughts on auto-completion and auto-formatting.
At the BlueJ team, we regularly get requests for new features. Two of the most requested features are auto-completion (of method names, imports and fields) and auto-formatting (a.k.a. “pretty-printing”) of code.
We have had these discussion since the very first release of BlueJ. So far, I have always refused to include these features. Is it time to re-think?
Should the BlueJ editor (“Moe”, as it is internally known) support automatic code formatting?
This question appeared on bluej-discuss last week again, as it did many times in the past.
So far, I have always argued against it. My argument is this: If students have this tool, they will get used to using it. By doing this, they will never have to think about doing indentation manually, and may not even appreciate the value of correct indentation (which you only notice once it is not there).
Then, when they leave BlueJ, as they inevitably will, if they end up in an environment that does not offer this feature, they are unable to do indentation properly. To teach the value and skill of indentation, students have to do it. Then, later, when you know you can do it, you can use a tool to automate it.
A similar discussion is popping up regularly about code completion.
Code completion, undoubtedly, is a very helpful tool to programmers. But the question is: does it help in learning to program?
My worry is that code completion may be used by students as an alternative to reading documentation. When you need a method, instead of going to the javadoc pages, you just hit the dot, and make a wild guess just by method name which one may be the method you want. Now, this technique may be moderately successful for people who more or less know what they are doing, but I would not want to teach it as a strategy to my students.
The danger plainly is: the presence of code completion may train bad habits, and prevent good ones.
(Note that I do not have anything at all against code completion for competent programmers. On the contrary – it’s a wonderful tool.)
Based on this reasoning, I have so far refused to add code completion or automatic formatting to Moe.
But should I change my mind?
During the original design of BlueJ and its editor, my guideline was always that the BlueJ editor should support all the functionality that is available in every standard work environment. But it should not automate important concepts that you may need to do manually later.
It seems to me that the goal posts are shifting. Today, just about every reasonable Java environment has code completion. Now, if this is becoming a standard feature that we can reasonably expect to be available wherever you work, then a large part of the argument against supporting it goes away.
Based on the principle that we should support the minimal standard toolset, and the assumption that code completion and auto-layout have become standard, we would have to conclude that we should support it now.
Times are changing. Or are they?
I was one of those people that asked Michael for automatic formating of code. He gave me the same response as he has written here. In our case we could see where Michael was coming from but still wanted it. Since the BlueJ editor is open source however we just added it. This gets around this particular issue for us. Others may want to think about doing this and infact others may already be doing this.
Mark
Please stick to your guns, Michael! Part of the beauty of BlueJ as an educational tool is its lack of “bells and whistles” which can get in the way of learning basic principles. When students are competent enough to benefit from labour-saving devices such as auto-completion and formatting there are plenty of “professional” environments which provide that.
At Sunderland (UK) we’ve just finished our first year of teaching with BlueJ and are really pleased with how it has enabled us to concentrate on key OO principles without extraneous complexity. I’d hate to see that elegance compromised by “feature creep”!
Paul.
I wouldn’t mind either feature under two constraints. First, the features should be enabled or disabled by directly editing the moe.defs file only. That would provide a bit of obscurity for those instructors who want to follow Michael’s original thinking regarding these features. Second, the features should default to “off” so that the new edition works just like old editions. It is easy enough to repackage BlueJ with them on if it is so desired.
Comment 3 from Todd Whittaker ist great.
In 2002/03 I learned Java with BlueJ – and did not miss things like code-completion. One, because I barely had to use code that was not mine anyway (and there were few small classes to program), and two, because I did not know about those things yet.
Nevertheless, I would vote for auto-completion in BlueJ, but only under the constraint that the JavaDoc comes along with the completion-suggestion so that it really could be an alternative to extra-reading the documentation.
I agree, wholeheartedly, with Todd (comment 3).
Good job.
its really nice to see code-completion/IntelliSense feature in BlueJ so it’ll be useful as a professional IDE… because using an IDE without code-completion is really a pain in the ass and time consuming too especially if you’ll be doing big Java projects already and no longer learning the basics of the language… both Eclipse and Netbeans are way to slow…
please do add this feature!
I believe that and argument can be made that code completion actually encourages good programing practices. First off, the utility of code completion increases rapidly as a function of the design of the frameworks it is used with. Well designed, well factored frameworks have simple, useful, object level protocols with, for example descriptive method names. Poorly designed frameworks do not. Using code completion can make the difference between well designed frameworks and poorly designed ones CONCRETE in a very real way. Secondly, code completion makes the collaboration between objects CONCRETE as well. This is the case for potential collaboration via inheritence, delegation, simple message passing etc. It makes these types of collaborations accessable and visible and also highlights the differences between them in a subtle but palpable way. And lastly, code completion does not obviate the need to read documentation. You can only glean so much from a method’s name, no matter how discriptive it is and how well refactored protocol might be, so you cannot escape reading the documentation, but the code completion gives you a pointer into the sometimes overwhelming documentation set. It gives you a place to start looking, which, IMHO, is also a good thing.
Code completion can be useful for students with accessibility issues. A couple of years ago we had two students with motor handicaps and code completion would have made it much easier for them.
I do undertand your concerns about bluej being a learning tool, but I use it at home with a slow machine, and the feature I miss is code completion due to using eclipse 3.2 at work with a more powerful CPU. Well,Im kind of addicted to code completion/formatting :).
As others have already said, it increases developers productivity and people with disabilities, so Im all for it, even as a separate download / plugin.
Thank you for BluJ.
I started reasonably programming with C and later C++. Now at my studies I was introduced to Java with BlueJ. I think code completion is not absolutely necessary. When you write code several times you will remember the words and spelling better. But as Ron Welch already mentioned in comment #9 a quick access to the api-documentation or a certain point where you can start looking is absolutely necessary, especially for students who are new to the language. I can remember my old Borland Turbo C++ 1.0 environment (from 1990) on which I started the programming. There was the possibility to write some code in the editor and then right-click on that word, so the IDE looked that word up in the (also integrated) help. I think the implementation of this feature would not be a great difference to the implementation of a code completion. It could be even much simpler when you just link to the search documentation page (but I don’t find that always appropriate for students because it gives back too many special and senseless results)
Ron
I have been a big fan of BlueJ since I first heard about it some years ago. It felt right. I recommended it to a number of folk wanting to learn programming.
But it wasn’t until March of this year that I had cause to use it personally. The setting was unusual, to say the least: Liberia, West Africa. (This is a country, ravaged by 20 years’ civil war, that has no mains electricity nor running water, not even in the capital, Monrovia). My wife and I had long supported a small vocational training institute there, which, incredibly has taught more than 1100 students some basic computer and/or administrative skills, using second-hand PCs shipped out in a contained from the UK, a diesel generator, and almost unfathomable dedication by a local team of Liberians. With some political stability now emerging, I visited to see if there was any merit in starting to think about inculcating the IT skills than might be needed 10 years from now. This included running a series of workshops for government and other officials, and a some informal attempts at actually doing some teaching myself – using BlueJ, of course. It was a very stressful environment: the PCs were slow, the room was teeming with students hungry to learn, and with little other support I was trying to get from machine to machine to keep them moving along.
Sorry for the long intro – now I’ll get to the point. The most significant negative factor in the process was caused by simple typing mistakes in your Java code. Some of these are easily spotted and some are not at all easy. (BTW another aggravating factor was that I had just spent two years working exlcusively in .Net languages so my Java was surprisingly rusty – even I was missing out semi-colons and missing braces. Yes, I should have been better prepared, but in another sense it gave me more of an understanding of the difficulties of starting programming). I have to say that I am completely convinced that having auto-complete and dynamic background compilation would have improved things enormously.
I myself wrote my first program in 1974. We had to punch the cards out on a manual 12-key punching machine. (I still remember that ‘(‘ and ‘)’ are 1-3-7 and 1-3-8 respectively). The turnaround time for our batch-run jobs was 48 hours (at a computer in another institution). Yes, we checked and double-checked our punch cards for accuracy. But I wouldn’t advocate a return to that environment.
By contrast, when I was young I was a poor speller – even though I was a keen writer and spent several years as a journalist. Off-line spell checkers would help me submit better copy but didn’t cure the problem. That changed in the late 1980s with the first word processor that did live (as you type) spell checking (I think the product was called FirstWord – it ran under the GEM GUI on top of MSDOS). I now have no difficulty spelling, even without such aids.
A long way of saying: IMHO auto-complete, method look-up, and dynamic background compilation encourage better programming, nor poorer programming.
(Unrelated comment: My main work is ‘Naked Objects’ – see http://www.nakedobjects.org. I would argue that Naked Objects is an obvious transition from BlueJ. It has many similarities: focus on the objects not the GUI, no main method etc etc.)
Richard Pawson – Naked Objects Group
I accept that you’ve designed BlueJ with teaching in mind, and you justify your feature decisions that way.
So … what are we trying to teach? Good programming pratices.
A key good programming practice is giving meaningful names to entities (variables, functions etc). I reviewed a student’s code and asked why a function that checks if a number is “perfect” was called “tester()” instead of “IsPerfect”. Answer: It’s too hard to type “IsPerfect” all the time.
Auto-complete removes that excuse, invites proper declaration of entities and then helps the programmer choose from the meaningfully-named, design-valid(declared) entities as s/he writes the code.
I think that’s a much more valuable lesson than learning how to do manual indentation.
I emailed the Blue J list asking for auto-formatting originally, great to see everyone’s thoughts on it.
“So far, I have always argued against it. My argument is this: If students have this tool, they will get used to using it. By doing this, they will never have to think about doing indentation manually, and may not even appreciate the value of correct indentation (which you only notice once it is not there).”
There’s a chicken and egg situation here. Although I strongly agree with this point, I often meet students who’ve never written neatly indented code and don’t realize how useful it is. Explaining the idea isn’t always enough, sometimes I’ll actually indent a method they’ve written myself to demonstrate how much easier it is to understand when it’s formatted nicely. When they experience that clarity for themselves, they’re happy to indent the code and realize why it’s important to do so.
If it were added to Blue J I’d like to see auto-formatting offered the way Netbeans provides it, requiring a user to manually request a re-format. Auto-formatting as you type (which I think emacs offers) doesn’t leave the student space to have that original thought and realization for themselves. Having no formatting control at all, IMHO, goes too far the other way, leaving students who have learned that lesson with the drudge work of having to format manually.