begin quoting Andrew Lentvorski as of Fri, Dec 02, 2005 at 09:54:45PM -0800:
> boblq wrote:
>
> >Now what does one gain with an IDE? I am not
> >trolling. I really would like to know what people
> >get out of these things.
>
> Autocompleting just about everything
This can be nice, especially if you're apt to make silly errors when
typing (e.g. "System.out.printnl"); the downside that I've noticed is
that this leads to programmers who aren't critical of code with really
long lines (because autocompletion saves typing!). So you might see
stuff like
public java.lang.String getValueFromPropertyUsingKey( String keyForProperty)
(Honest to goodness, saw this just last week. In production code.)
The other extreme, [ e.g. public String g( String k ) ] isn't a reason to put
up with this sort of thing.
> Popup documentation of functions
Also useful, although I've been in the habit of keeping a browser up at
a Javadoc API page (for Java and local code) when writing Java or a
terminal for man lookups of C calls for years. Popup anything is
annoying, although I imagine with enough effort / exposure you can get
used to it.
There are vim plugins that let you jump _to_ the function (and thus
the documentation) in a couple of keystrokes, but I find I use this
less than generating the javadoc for the module and bringing it up
in the browser.
> Overall code visualization and navigation (ie. outline views with
> color/icon views showing things like public/private/static at a glance)
To me, utterly useless while coding. Useful while refactoring, sometimes.
(What's a circle mean versus a square? And WTF is a triangle for?)
> Syntax sensitive editing (ie. can rename someVariable just within a
> function, a module or project without affecting those you don't want)
I'd want to check all usages anyway before renaming, anyway, as the
most common reason for renaming (for me) is to undo a conflict.
If you have so much code that you can't easily track this, you're
into refactoring land...
> Refactoring and hoisting assistance in the editor
I use a standalone refactoring tool (RefactorIT), so integration into
the environment/editor might be nice, but it hasn't been necessary. Esp.
now that vim will autoload changed files for me.
> Style suggestions which may not be pure errors
I hate "suggestions" when I'm typing something in. I much prefer a
post-processing step if I'm going to use such things. Don't distract
me with irrelevent nonsense; when I want suggestions, I'll ask for 'em.
There's a general presumption that the tool is smarter than the
developer in this sort of setup -- the fact that it's often true doesn't
make it any less annoying.
Some environments will also automatically reformat code for you to your
preferred style. This is great for cleaning up inconsistent styles in
code, but if your style isn't quite set properly, you can end up making
a lot of changes that run counter to the project's official style.
(I've denied commit access to developers who upgraded their IDE and lost
the style settings...)
> Lots of stuff which can be displayed at the relevant point in the editor
Alas, it will generally be displayed regardless, cluttering the view. :(
(Or you figure out how to hide it, and then can't remember how to get it
back when you finally want it.)
> buffer rather than requiring hunting between separate messages.
Not sure I follow.
> Automatic updating of references when you rename a file (ie.
> import/include statements and the like)
See standalone refactoring tool above. :)
> Full Unicode support
Never needed it. Not sure I want it for code.
> On-the-fly editing of code inside the debugger which can then be
> immediately pulled into the environment during debugging
Surely that should be a feature of the debugger?
Besides, I wouldn't trust such things. If I modify the code, I'll still
have to restart it from scratch to make sure the change actually did the
right thing.
> Certain languages require more boilerplate than they should (Java being
> an offender/C# also being in that category). IDE's tend to smooth out
> the differences between those languages and something like Perl or
> Python which isn't so verbose.
Abbreviations, templates, and code generators are generally how I handle
boilerplate code. Although, the folks I work with who use IDEs simply cut
and paste from other programs, and use the change-name features to
update it.
> From my point of view, IDE's allow more information to be present on my
> screen at a simultaneous glance than anything else.
I've yet to figure out how to get it to display the information I want
to see rather than the information the designers thought it was
important I had access to.
If the information you want to see is there already, an IDE would be
a godsend. If you have to fight the tool to get at the information you
want, it's a barrier.
If I'm using only xterm for development, my typical layout is something like:
+------------------------------+
| |
+------------------------------+ +------------------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| |---| |
| | | |
| | +------------------------------+
| |
| | +------------------------------+
| | | |
| |---| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+------------------------------+ +------------------------------+
| |
+------------------------------+
I generally have code up on at least two windows; one window for
building; one window for test-runs; one window for 'research'
(although for Java, I prefer a browser and a second monitor).
This varies depending on the size of the monitor, the capability to
use virtual desktops, the presence of a second monitor, etc.
The default behavior of gvim is to spawn a window and detach, which
generally leads to more gvim windows and fewer terminal windows,
as I only need one "editor" window.
-Stewart "The best programming aid is a second monitor." Stremler
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
