Re: Issue 3330: redo much of the stencil stacking/spacing/empty-check (issue 8869044)

[dak]

On 2013/04/29 07:35:05, janek wrote:
> On 2013/04/28 23:16:28, dak wrote:

> ok, and i agree that adding a comment like this into the source may
not be a
> good idea.  However, git commit message has a different purpose (to
myself at
> least); i want to know why something changed.  When i'm searching
lilypond
> history to learn something about the code i'm trying to modify, my
usual problem
> is that i find a change and the commit message just says what changed
- it
> doesn't answer my questions: "what was wrong with previous version?
Was this
> just a cosmetic change that accidentally introduced a bug, or was some
other
> design idea behind it?"
> I'm pretty surprised by your opinion here since you always advocate
writing hows
> and whys into commit messages.

Which is why the how and why is written in the commit message for the
changed behavior of Box where it belongs.

[...]
> > type/precision than that stored in Interval, making the comparison
fail.  It's
> > not like the C++ compiler would generate a lot of code here, and I
can
> probably
> > even leave off the set_empty as it should be the default.

> ok.

Phrased differently, I was lazy and wanted to avoid looking every
implementation detail up in order to get this do the right thing because
I worked diligently rather than it getting to do the right thing as it
obviously can't do anything else.

But then if I am too lazy to look up every detail when writing, do I
really want the reader to have to look up every detail when reading
and/or debugging the code?

Better leave the stuff written in a manner where it's immediately
obvious that it does the right thing.

https://codereview.appspot.com/8869044/