[Top][All Lists]

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

Re: Fixes bad slur heights by limiting fit_factor to the interior of slu

From: address@hidden
Subject: Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)
Date: Sun, 7 Aug 2011 11:46:51 +0200

On Aug 7, 2011, at 11:33 AM, Janek Warchoł wrote:

> 2011/8/6 address@hidden <address@hidden>:
>> On Aug 6, 2011, at 11:09 AM, address@hidden wrote:
>>> i tried writing a review, but i don't understand what's going on here.
>>> Can you add some comments to the code?
>> The function fit_factor pushes up the height of a slur if there is an 
>> extra-encompass-object in the way.  My change makes this function ignore all 
>> extra-encompass-objects close to the extremes of a slur, as these objects 
>> have a tendency to push a slur up disproportionately high.  These objects 
>> are still penalized in the scoring, which results in their avoidance if 
>> possible.
> Thanks.  Could you add this to the source as a comment?
> This sounds reasonable, however i still have a hard time reading this
> code because variable names aren't descriptive...  What dz_unit,
> dz_perp, curve_xext are?  What pext.intersect (curve_xext) does?
> cheers,
> Janek

Hey Janek,

I'm certainly not against adding comments, but I think that when the code does 
a good job of explaining stuff via variable names, comments can clutter what's 
going on.  For example, dz_unit to me sounds like a unit vector (which it is), 
dz_perp is the vector perpendicular to this, and curve_xext is the extent of 
the curve from attachment point to attachment point.  This could potentially be 
the subject of a future GOP, but I am of the opinion that if code is easy to 
read because of good variable naming, it is not necessary to add more comments.


reply via email to

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