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

[Kim F. Storm]

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