An example of nice boolean usage is: paintTextWithShadows(context, font, textRun, 0, length, length, textOrigin, boxRect, textShadow, textStrokeWidth > 0, isHorizontal()); GOOD!
The last parameter is a boolean indicating whether or not the text run is vertical text or horizontal text. It would be unreadable if you passed raw true or raw false to the function, but all the call sites pass isHorizontal(), so it's perfectly fine. paintTextWithShadows(context, font, textRun, 0, length, length, textOrigin, boxRect, textShadow, textStrokeWidth > 0, true); BAD! dave (hy...@apple.com) On Dec 3, 2010, at 4:30 PM, Darin Adler wrote: > On Dec 3, 2010, at 1:37 PM, David Hyatt wrote: > >> The only exception I would make to this rule is if all the call sites use >> variables and never pass in raw true or false. In that case there's no loss >> of readability, and whether you use an enum vs. a bool is irrelevant. > > That’s right. There are cases where the boolean value passed in for a > particular argument is typically the result of a boolean expression or > boolean-returning function. We have definitely seen these in patch review. > >> I think in general the rule should be "Keep your call sites readable, and >> convert to enums if you find that the call sites are becoming inscrutable." > > Beyond the enum guidelines, it’s also true that functions with these > boolean/enum arguments often indicate minor design mistakes. Many times we > would be better off with multiple functions rather than a single function > with an enum argument. > > -- Darin > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
