Re: Gtk{Tree,List} replacement proposal
- From: Maciej Stachowiak <mjs eazel com>
- To: Havoc Pennington <hp redhat com>
- Cc: Jonathan Blandford <jrb redhat com>, gtk-devel-list gnome org
- Subject: Re: Gtk{Tree,List} replacement proposal
- Date: 03 Jul 2000 17:22:33 -0700
Havoc Pennington <hp@redhat.com> writes:
> Maciej Stachowiak <mjs@eazel.com> writes:
> > First of all, I rpopose we use TreeList everywhere instead of TL. It's
> > a lot more clarity and not much more typing. There are already classes
> > in Gtk with longer names than either GtkTreeListView or
> > GtkTreeListModel, and many with names of similar length.
> >
>
> This is way too long. I vote for TLView.
Why do you think it's way too long? I came up with some stats for Owen
a while back and there were a lot of classes in current Gtk 1.3
(30-ish total?) that have names longer than this, as long, or shorter
by no more than two characters (and no, it's not that heavily
overbalanced to the short end).
More importantly, clarity is more important than brevity. With a good
text editor, suitably configured, entering longer identifiers is not
that hard. But reading the code is a _much_ more pleasant experience
if the identifiers are meaningful. Compare Nautilus code to projects
that favor brevity over clarity and see which is easier to read and
understand (please except nautilus-window-manage-views.c from this
comparison :-).
In all seriousness, if I saw TLView in code and I didn't already know
what it was, I'd be majorly confused. Abbreviations are OK when it's
obvious and well-established what they mean (H, V, min, max, init for
instance). Darin would go farther than that and claim abbreviations in
identifiers are never OK, but I'm not quite that radical personally.
What do you think of all the function rename suggestions?
> Or GtkZTree. On the "this is the last one dammit" principle. ;-)
Never say never. :-)
- Maciej
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]