This started as a promising missive on whether we should consider some radical new editing modes such as for example treating a source file as a tree of nodes instead of a stream of characters...
and then devolved into a silly vi fanboy rant. Shame. Before you get too offended, let me explain why your advice is not something folks should be following: 1. It's programming, not writing your third grade english assignment. Speed of typing is a tiny smidge of the total time you spent developing. Reading code, fixing bugs, and refactoring things is going to take up about 1000x more time than writing stuff. If you suck at using your tools correctly, and you for example do all your refactoring 'by hand', then, yes, being a dumb text terminal genius is going to help you some, but make it easy on yourself and go straight to the source: Learn to use all those fancy scripts. 2. Mousing is an activity performed by the spatial centers of the brain. Keyboard nav, especially the vi-style targetted approach (not holding down a cursor key until the cursor moseys on over to where you want to go, but using incremental search or targeted commands like 'to the end of this block') is mostly done by the same part of your brain that is thinking about programming in the abstract and is busy reading text. The somewhat weird side-effect of firing up the old spatial processor to e.g. select something with your mouse, you get a time dilation sense: It _FEELS_ slower. It isn't, though. Time a vi wizard selecting some text and some poor sap with a mouse and you'll notice the vi jockey's speed is only a fraction faster than the standard keyboard+mouse model. Seriously. Get a stop watch. Your body's sense of time can't do this right and adamantly insists keyboarding is faster when it rarely makes much of an impact. Having said all that, there's still value in knowing how to use your IDE correctly. So, if you really want to improve productivity, don't bother with a vi plugin. Look at features your editor already has, and start using them. A sampling of suggestions: - Seriously, debuggers rock. They are complicated tools that are absolutely amazing at helping you find bugs or even just figuring out how something works when you need to maintain something. There's a reason smalltalk still has a following, because they were right. Start debugging stuff. Use every feature. Learn how to add breakpoints, and then evaluate expressions on the spot. Once you've learned this, you can take those smug LISPy bastards and tell them to shove their REPL - java pretty much has all that and more, *WHEN* you know how to use a debugger. Eclipse's is great. So is netbeans. I presume IntelliJ's is not too shabby either. - Especially on windows and some linux distros, the out-of-the-box font just blows. It's a continuous source of stress and productivity drain that you never notice until you fix it, so, _GO FIX IT_. Download inconsolidata RIGHT NOW and install it in your editor. You can thank me later. Inconsolidata: http://www.levien.com/type/myfonts/inconsolata.html - or if you don't like that, some alternatives: http://hivelogic.com/articles/top-10-programming-fonts - and do this even if you do own a mac or work on ubuntu. Monaco is pretty good, but inconsolidata and most others on Dan's top 10 handily beat it. - Learn how to use refactor scripts. Write code without consideration of DRY or 'good scalable' design, so DONT make needless factories and interfaces for stuff. Instead, go about your business and when you realize you're writing the same thing for the third time, go back and _refactor_ your way out of it. This approach is faster and leads to much better code in the long run. You can for example take an inlined expression and extract it into a local variable, you can extract an interface from a given class AND replace all users of your class with it, you can of course rename public members of classes and automatically let other code referring to this member rename their access calls too, and you can move methods up and down class hierarchies. - *SOME* keyboard shortcuts are good to know. Just don't get married to the idea of them like a vi or emacs user. On mac eclipse, CMD+dot (the '.' key) goes to the next problem, which is very very useful. CMD +J starts incremental search mode. Just start typing the thing you wanna go to, and you're there. Hit enter to exit this mode. Or hit CMD +J while in incremental search mode to hop to the next search result. Check your editor's keys preferences pane, it's a gold mine. Also, ALT +stuff is useful (alt+keys moves a word at a time, ALT+backspace or delete deletes entire words, and SHIFT+ALT+cursors selects words at a time). Just set up a daily task for yourself: Look at 10 keyboard shortcuts in your editor's keyboard pref pane every day, figure out what they do, and if something seems useful, write it down and force yourself to use it for a while. At some point it'll end up in your muscle memory and you've learned it for life! - Master source navigation. Use the 'backward history' shortcut key (CMD+[ in eclipse?). Use 'go-to-declaration' (cmd+click on item, or F3?). Use 'find callers' (CTRL+ALT+H). Use 'go-to-type' (CMD+SHIFT+T), go-to-resource (CMD+SHIFT+R), and show outline (CMD+O?) to go places, never use the package explorer. Know that you can use camel casing both in the go-to-type dialog as well as autocomplete. So, to use an arraylist, just write "new AL" and hit ctrl+space or whatever you have setup as autocomplete. Apologies for the uncertainty on the exact keyboard shortcuts. I've rewired a few of mine, so I'm going by memory here. - Write macros. Use them. I've got a macro for nullcheck, for example. I type 'nullcheck', hit ctrl+space, and voila. If my method has only 1 parameters, it's all filled in and I can immediately hit enter and continue with the next statement. If it's got more than 1, I just type the name of the variable, hit enter, and that's that. The macro feature is powerful but the default macros suck, at least on eclipse, so you'll need to do some customization work first. If you find yourself typing the same thing a lot, but its not something you can abstract away, macros are probably the answer. Well, that, or project lombok </shameless plug>. Rewrite the default snippets eclipse inserts when letting eclipse make stuff, because the out-of-the-box templates are awful. Most likely you want to dump all the gunk that's in there and keep it light. On Jan 20, 7:57 am, jamesj <[email protected]> wrote: > It it interesting to me that in the time that I have listened to the > podcast, I have heard lots of banter about which IDE is better, but no > discussion about the editing paradigm. IDEs tend to do editing using > familiar word processor actions. Watch someone coding in windows some > time and see how many times the user has to switch from mouse to > keyboard and back and shift positions. Then, go watch some of the old > guys that use either VI or Emacs. If you haven't used them before, > you will probably be confused with the strangeness of what they do, > but also surprised at the speed and productivity. I coded for > several years before I had to learn Emacs because I had to work on > Unix, and then shortly thereafter, a seasoned veteran talked me into > trying VI for a week. (For those who haven't used them, Emacs is a > “chording” editor. I.e. it uses lots of ctrl-shift-? combinations. > VI is a “state” editor, where the keyboard is either in text entry > state or in a command state.) What makes this most interesting to > this list, is that modern IDE's support alternate editing models > through plugins. > > When I use Eclipse or Netbeans I do my editing using a VI style > plugin. For me, I prefer the VI “state” approach over the Emacs > “chording”. For Eclipse you have to buy the good plugin > (www.viplugin.com), which is very reasonably priced, and for Netbeans > there is a good free one (jvi.sourceforge.net). If you have never > tried VI you may consider just trying it. > > You should give yourself several days to learn it, and should keep a > note sheet beside you. On the sheet write down the most basic > commands and as you need more, add them. Eventually you will quit > trying or will just put away the sheet because you don't even think > the commnads any more, stuff just happens. The best part, is that > with the plugins, a simple click on the toolbar will get you back and > forth between the standard and the VI mode. > > For those of you who haven't tried it yet, here is a bare-bones > tutorial and a few of my favorite things that hurt me to do without > VI. > > (esc) - switches you to command mode. (anyone using VI hits this a > lot) > > once in command mode, > (a) or (i) - gets you back to editing mode > (A) - gets you back to editing mode after jumping to the end of the > current line > > (h) - move left > (l) - move right > (j) - down > (k) - up > (^) - jump to beginning of line > ($) - jump to end of line > (x) - deletes one character or selection > (dd) - deletes the whole current line > (4dd) - deletes 4 lines (and you can use whatever count you want) > > (Y) - called yank in vi, cuts a whole line > (4Y) - would cut 4 lines > > (p) - pastes stuff that was yanked. > > vi supports multiple buffers, so that you can yank multiple things > into specific buffers an then paste them from those buffers. > > VI supports simple macros that can be defined and used with 2 or 3 key > strokes. A typical use is something like this: I needed the states > and postal abbreviations, so I found a page on the web, cut and pasted > into my editor, started a macro, made the editing necessary to convert > the first line to a line of code followed by a move to the next line, > end the macro, then invoke it 50 times. You can't even begin to write > a script to do this simple stuff in the time it takes to do it. But, > it does require some creativity on your part to describe what you want > in generic editing motions. > > If you have fun with this stuff, go find a real tutorial and find the > best 2% that you want to use. It is definitely not for everyone, but > for me, it was one of the best investments of time that I have ever > made, and I just wanted to pass along the tip to the next generation.
-- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
