![\"Complete\"](\"http:\/\/www.bluej.org\/mrt\/wp-content\/uploads\/2006\/07\/complete.jpg\")
\nSome thoughts on auto-completion and auto-formatting.
\nAt 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.<\/p>\n
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?<\/p>\n
\nShould the BlueJ editor (“Moe”, as it is internally known) support automatic code formatting?<\/p>\n
This question appeared on bluej-discuss last week again, as it did many times in the past.<\/p>\n
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).<\/p>\n
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.<\/p>\n
A similar discussion is popping up regularly about code completion.<\/p>\n
Code completion, undoubtedly, is a very helpful tool to programmers. But the question is: does it help in learning<\/em> to program?<\/p>\n 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.<\/p>\n The danger plainly is: the presence of code completion may train bad habits, and prevent good ones.<\/p>\n (Note that I do not have anything at all against code completion for competent programmers. On the contrary – it’s a wonderful tool.)<\/p>\n Based on this reasoning, I have so far refused to add code completion or automatic formatting to Moe.<\/p>\n But should I change my mind?<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Times are changing. Or are they?<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading