3 ms·
Your example is sort of self-defeating insofar as who would ever type code that looked like do_thing(x, y, x); do_other_thing(a, b, c); to_the_deat
by aston 19y ago
Your example is sort of self-defeating insofar as who would ever type code that looked like
do_thing(x, y, x); do_other_thing(a, b, c);
to_the_death(j, k, l); to_the_pain(wfb);
do_thing(c, f, e); do_other_thing(t, t, q);
#etc for maybe a dozen lines.
? And what IDE wouldn't make that pretty from the get go? And why would you have more than one instance of something like two functions needing positions switched when that could've been refactored out? Very artificial example, and even still doesn't demonstrate the strength of Emacs over somethink like Visual Studio.
- Goladus 19y agoI took that example directly from a task that I had myself a short while ago. It is likely to happen any time you must deal with volumes of real data. It's true that if you are using lisp, that particular scenario (which is narrow, not artificial) will be less relevant. But if you are developing in Lisp, Visual Studio is not a real option anyway. The thing is, any time you need to move a bunch of text around that may not exactly conform to your particular object hierarchy, keyboard macros can make the task trivial. If you do decide to completely refactor, keyboard macros help you there as well. This particular example was inspired by a lexical definitions file, which is a series of regular expressions with code attached to each one. Here's a sample from my actual code: "!" {lexer_debug(yytext, SIMPLEOP_BANG); yylval.ptnode = lex_leaf(SIMPLEOP_BANG, NULL); return SIMPLEOP_BANG;} "%" {lexer_debug(yytext, SIMPLEOP_REMAINDER); yylval.ptnode = lex_leaf(SIMPLEOP_REMAINDER, NULL); return SIMPLEOP_REMAINDER;} What this says is that when the lexer encounters an exclamation point, it first calls a debug function with the text it found and the associated token enum. Then, it creates a leaf node and assigns the result to yylval.ptnode, then it returns the token enum. I have 66 different definitions in the file. Each one passes unique arguments to the various functions. It is difficult to compress the code much further than this. There is very little to be gained by combining everything into one function. Some of the tokens (braces and constants, in particular) have additional code that must be run. If I tried to refactor, I'd have to create a new conditional framework to account for the special cases (either a switch or function pointers since this is C). That would increase logical complexity (the lexer already did the comparison, why do it again?), incur performance overhead for no good reason, and ultimately would not gain me much in the long term. My original code had the debug function and the leaf function backwards. I needed to fix that. I had two options. I could refactor the whole damn thing and debug the result (which would include 6 special cases), or I could spend 60 seconds recording a keyboard macro and 10 to execute it 60 times. Option two is simply not an option in Visual Studio. Another example: Suppose you're using python and have a whole bunch of functions to wrap in classes. The one drawback of 'the whitespace thing' is that if you try to use tabbing to do this it's easy to make a few mistakes and screw up your block structure. It's better to just insert X spaces at the beginning of each line. I made a macro to do exactly this, and can easily bind it to F8 whenever I need to use it. I use F7 and F8 as my utility keys, for functions I don't use all the time but need to be fast when I do use them. I'll probably eventually write a function that will let me cycle the behavior of my function keys sort of like the ability bar in World of Warcraft. That's basically what minor modes are for already (though I don't know how to use them yet).