From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: Code cleanup -- inconsistent "width" and "height" etc.
Date: 10 Apr 2003 15:50:50 +0200 [thread overview]
Message-ID: <5xptnuihqd.fsf@kfs2.cua.dk> (raw)
In-Reply-To: <buo65pnqgqv.fsf@mcspd15.ucom.lsi.nec.co.jp>
Miles Bader <miles@lsi.nec.co.jp> writes:
> storm@cua.dk (Kim F. Storm) writes:
> > Things measured in columns/lines are named as _CANON_WIDTH and
> > _CANON_HEIGHT resp., while things measured in pixels are named as
> > _PIXEL_WIDTH and _PIXEL_HEIGHT resp.
>
> `_CANON_WIDTH' sounds annoyingly redundant; if that's the canonical
> representation, then just use `_WIDTH,' and save additional adjectives
> for exceptional cases.
Alternatively, we could use *_COLS in general as a short precise name
when the width is measured in columns (the canonical X unit).
Similarly, we could use *_LINES for heights measured in lines (the
canonical Y unit).
If we do that consistently, we could simply use *_WIDTH and *_HEIGHT to
mean pixel width and height.
For example, we would use FRAME_COLS and FRAME_LINES rather than the
current FRAME_WIDTH and FRAME_HEIGHT.
And, if necessary, FRAME_WIDTH and FRAME_HEIGHT would now be measured
in pixels; they could be defined as
#define FRAME_WIDTH(f) (FRAME_COLS (f) * FRAME_CANON_X_UNIT (f))
#define FRAME_HEIGHT(f) (FRAME_LINES (f) * FRAME_CANON_Y_UNIT (f))
I like this -- it is simple (names are still short) and precise!
WDYT?
>
> Adding unnecessary verbosity simply makes the code more tedious (and
> thus harder) to read.
Maybe, but it definitely cannot be harder to _understand_ than the
current code that uses all those inconsistent names.
>
> [For the same reason, such adjectives _shouldn't_ be used in cases where
> only one representation is possible by definition; e.g., the width of a
> character in a font is obviously in pixels, so adding `_pixel' would be
> unnecessary and harmful.]
Actually, with the above proposal, FONT_WIDTH and FONT_HEIGHT
(measured in pixels) would be consistent with the new naming rules.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2003-04-10 13:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-10 1:51 Code cleanup -- inconsistent "width" and "height" etc Kim F. Storm
2003-04-10 0:11 ` Kenichi Handa
2003-04-10 1:32 ` Miles Bader
2003-04-10 13:50 ` Kim F. Storm [this message]
2003-04-10 12:10 ` Kenichi Handa
2003-04-11 0:08 ` Kim F. Storm
2003-04-10 23:27 ` Miles Bader
2003-04-11 0:34 ` Kenichi Handa
2003-04-11 23:45 ` Richard Stallman
2003-04-12 2:19 ` Kenichi Handa
2003-04-11 8:51 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5xptnuihqd.fsf@kfs2.cua.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).