[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code cleanup -- inconsistent "width" and "height" etc.

From: Kim F. Storm
Subject: Re: Code cleanup -- inconsistent "width" and "height" etc.
Date: 10 Apr 2003 15:50:50 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Miles Bader <address@hidden> writes:

> address@hidden (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
> `_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

And, if necessary, FRAME_WIDTH and FRAME_HEIGHT would now be measured
in pixels; they could be defined as


I like this -- it is simple (names are still short) and precise!


> 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 <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]