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
