On Sun, 2004-12-12 at 23:24, Bill Kendrick wrote: > On Sun, Dec 12, 2004 at 08:53:55PM -0500, Albert Cahalan wrote:
> > 1. The usage of mixed tabs as spaces prevents me from > > using a block indent command. (^K-,) Either spaces > > or tabs would be fine, but not mixed. > > I blame VIM! Damned thing!!! I used to use only emacs, but have > been finding VI varients load a LOT quicker, plus take the least effort > to get syntax highlighting going. Beyond that, though, it's actually quite > a pain in the butt to use. That explains the use of default emacs style with errors. > Maybe we should throw the code through prettyprint or something? These are pretty standard: indent -kr -ncs -i8 (Linux kernel style) indent -kr -ncs -nut -i4 (what many people like to read) indent -kr -ncs -nut -i2 (close to my usual style) > > 2. The indentation of '}' breaks autoindent. My editor > > does not contain a whole figgin LISP interpreter and > > a LISP compiler and LISP libraries and a kitchen sink. > > BTW, this also causes the human to make many errors. > > Can you explain this one? Do you mean the Emacs style of this: > > > if (blah) > ..{ > ....stuff(); > ..} > > If so, then yeah... it's a pain when PARTS of the code is indented > like that, and others are indented in the more standard way: > > if (blah) > { > ..stuff(); > } Yes. While I'd much rather have the '{' on the line above, it's the indented '}' that kills me. Things just don't line up right, so it's hard to tell if I'm editing correctly. > Also, way down at the end of the to-do-list in my brain is a note to > break tuxpaint.c up into sane pieces. It wasn't a big deal when the code > was only ~2000 lines long, but now that it's reaching 15,000 it's getting > a little insane. (I can still navigate the code with relative ease... it > just takes far longer to compile than it should.) That crossed my mind too. Then I thought, hey, having it in one big blob might make it run a tiny bit faster. I can search. (the compiler can cheat on the ABI for intra-file calls) You can save 1325 lines by moving the '{' up to the previous line. :-) That's an over 9% reduction. A bigger concern for me is the cascaded if...else stuff. Combined with the odd indentation, I often get very lost. The performance won't scale, though it's hard to tell how much of a problem this is. I'd use structs containing function pointers. So the active tool is defined by a pointer to a struct with methods for handling a mouse click, mouse move, mouse release, selection of the tool (for initialization), selection of some other tool (for freeing memory), and so on. Then the tools can be more self-contained, not having scraps of code all over. _______________________________________________ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev