Re: [webkit-dev] Bools are strictly worse than enums
On Dec 6, 2010, at 10:15 AM, Darin Adler wrote: > On Dec 4, 2010, at 3:01 PM, Maciej Stachowiak wrote: > >> Passing a true or false literal (at least in cases where it's not the sole >> argument) is a likely indicator of unclear style, as opposed to taking a >> boolean argument. > > Agreed. > >> In fact, even putting a boolean literal in a named variable and then passing >> that is likely to be fairly clear. > > Use of a boolean literal can easily hide the fact that a call site is passing > a boolean to the wrong argument or even has the sense of the boolean > backward. The enum technique is considerably more powerful in the way that it > ties the call site to the called function, providing a benefit that goes > beyond readability. > > That having been said the enum has at least these costs: > > - The enumeration definition has to be in a file included anywhere it’s used. > - Coming up with good names for the enumeration and its values can be > difficult. > - At call sites that need to compute a value to pass in rather than passing a > constant the enum can obscure the code’s meaning rather than clarifying it. > - Mangled names of functions get longer. I find one other cost when converting to enums. Since C++ doesn't do typing of enums, you have to worry about name clashes. This leads to enum names decorated with the enum type. Putting the enum in the associated class helps. But as the use of enums goes up you even have to worry about clashes within the class. Plus putting enums in a class requires qualifying each enum with the class name. All these things lead to reduced readability. I haven't found any guidance in the style guidelines about naming and qualifying enums. Right now you see every manner of enum naming imaginable. Adding something to the style guidelines would be very helpful. I agree that using enums is better. But I'd like to get some guidance on how to do it "right". - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Dec 4, 2010, at 3:01 PM, Maciej Stachowiak wrote: > Passing a true or false literal (at least in cases where it's not the sole > argument) is a likely indicator of unclear style, as opposed to taking a > boolean argument. Agreed. > In fact, even putting a boolean literal in a named variable and then passing > that is likely to be fairly clear. Use of a boolean literal can easily hide the fact that a call site is passing a boolean to the wrong argument or even has the sense of the boolean backward. The enum technique is considerably more powerful in the way that it ties the call site to the called function, providing a benefit that goes beyond readability. That having been said the enum has at least these costs: - The enumeration definition has to be in a file included anywhere it’s used. - Coming up with good names for the enumeration and its values can be difficult. - At call sites that need to compute a value to pass in rather than passing a constant the enum can obscure the code’s meaning rather than clarifying it. - Mangled names of functions get longer. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Dec 3, 2010, at 2:08 PM, Alexey Proskuryakov wrote: > > 03.12.2010, в 13:54, Eric Seidel написал(а): > >> I'm not sure we have any examples of bool passing like that in real code. > > > We do, although I can't provide one now. I just remember this being discussed > in bug review. > > I think that Dave's rule is best here, even if it meant that we couldn't > check it automatically. But I think that we can try - just complain each time > true or false is passed into a function. That may prove to be too chatty > though. That sounds about right to me. Passing a true or false literal (at least in cases where it's not the sole argument) is a likely indicator of unclear style, as opposed to taking a boolean argument. In fact, even putting a boolean literal in a named variable and then passing that is likely to be fairly clear. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, Dec 3, 2010 at 2:42 PM, David Hyatt wrote: > 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. > Furthermore, the second-to-last arg here looks like a bool too, but "textStrokeWidth > 0" seems a lot more obvious to a reader than "true". PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
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
Re: [webkit-dev] Bools are strictly worse than enums
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
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, Dec 3, 2010 at 2:08 PM, Alexey Proskuryakov wrote: > > I think that Dave's rule is best here > I second that. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, Dec 3, 2010 at 1:55 PM, Nico Weber wrote: > Out of curiosity, what do people think of > > doSomethingElse(/*paramName=*/true); > > when calling an existing function that takes a bool? > Why don't we just change it to take enum instead? Adding a comment to repeat the argument name in call sites seems to contradict all other coding principles we have in WebKit. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
03.12.2010, в 13:54, Eric Seidel написал(а): > I'm not sure we have any examples of bool passing like that in real code. We do, although I can't provide one now. I just remember this being discussed in bug review. I think that Dave's rule is best here, even if it meant that we couldn't check it automatically. But I think that we can try - just complain each time true or false is passed into a function. That may prove to be too chatty though. 03.12.2010, в 13:55, Nico Weber написал(а): > Out of curiosity, what do people think of > > doSomethingElse(/*paramName=*/true); There is a horrible failure case - if the comment is wrong (or gets wrong after a refactoring made elsewhere), it gets much worse than an unannotated boolean argument. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
Again, I think enum is better. I am just saying that method(true /* xxx */) is not as bad as method(true, true, true, false); On Fri, Dec 3, 2010 at 5:01 PM, Eric Seidel wrote: > I think /* explanation of what I'm doing */ is strictly worse than > readableCode(UnderstandableParameter). > I'd rather have readable code than comments attempting to excuse unreadable > code. > -eric > On Fri, Dec 3, 2010 at 1:57 PM, Antonio Gomes wrote: >> >> I do not think that XXX:repaint(true /* immediate */) is so bad >> either, if I understood Hyatt's comment correctly, and I agree with him on >> it. >> >> Having a enum is ideal, but no need for it to be mandatory, as other >> also pointed out. >> >> On Fri, Dec 3, 2010 at 4:54 PM, Eric Seidel wrote: >> > I'm not sure we have any examples of bool passing like that in real >> > code. >> > The case I'm concerned about is not one of single argument bools: >> > doSoemthing(bool) >> > but more of multi-argument functions: >> > doSomething(something, bool) >> > I'm trying to write a rule which can be easily automated by >> > check-webkit-style. >> > It's possible we could tighten the rule further to only allow >> > single-argument bools where "set" is in the function name. >> > It sounds like most folks are in agreement. We should add a rule like >> > this >> > to check-webkit-style. Sounds like Dave Levin may already have >> > something >> > partial in the works. >> > -eric >> > On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa wrote: >> >> >> >> On Fri, 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. >> >>> 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." >> >> >> >> That rule makes sense to me. >> >> On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel wrote: >> >>> >> >>> Dave, I'm not sure I understand your exception. Could you give an >> >>> example? >> >> >> >> I think what he means is that >> >> bool doSomething(); >> >> void doSomethingElse(bool); >> >> and the only case we always call doSomethingElse with a return value of >> >> some function or with a variable: >> >> doSomethingElse(doSomething()); >> >> doSomethingElse(shouldNotDoSomethingElse); >> >> etc... >> >> and we never call it with raw true/false: >> >> doSomethingElse(true) >> >> doSomethingElse(false) >> >> - Ryosuke >> >> >> >> ___ >> >> 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 >> > >> > >> >> >> >> -- >> --Antonio Gomes > > -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
I think /* explanation of what I'm doing */ is strictly worse than readableCode(UnderstandableParameter). I'd rather have readable code than comments attempting to excuse unreadable code. -eric On Fri, Dec 3, 2010 at 1:57 PM, Antonio Gomes wrote: > I do not think that XXX:repaint(true /* immediate */) is so bad > either, if I understood Hyatt's comment correctly, and I agree with him on > it. > > Having a enum is ideal, but no need for it to be mandatory, as other > also pointed out. > > On Fri, Dec 3, 2010 at 4:54 PM, Eric Seidel wrote: > > I'm not sure we have any examples of bool passing like that in real code. > > The case I'm concerned about is not one of single argument bools: > > doSoemthing(bool) > > but more of multi-argument functions: > > doSomething(something, bool) > > I'm trying to write a rule which can be easily automated by > > check-webkit-style. > > It's possible we could tighten the rule further to only allow > > single-argument bools where "set" is in the function name. > > It sounds like most folks are in agreement. We should add a rule like > this > > to check-webkit-style. Sounds like Dave Levin may already have something > > partial in the works. > > -eric > > On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa wrote: > >> > >> On Fri, 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. > >>> 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." > >> > >> That rule makes sense to me. > >> On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel wrote: > >>> > >>> Dave, I'm not sure I understand your exception. Could you give an > >>> example? > >> > >> I think what he means is that > >> bool doSomething(); > >> void doSomethingElse(bool); > >> and the only case we always call doSomethingElse with a return value of > >> some function or with a variable: > >> doSomethingElse(doSomething()); > >> doSomethingElse(shouldNotDoSomethingElse); > >> etc... > >> and we never call it with raw true/false: > >> doSomethingElse(true) > >> doSomethingElse(false) > >> - Ryosuke > >> > >> ___ > >> 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 > > > > > > > > -- > --Antonio Gomes > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
I do not think that XXX:repaint(true /* immediate */) is so bad either, if I understood Hyatt's comment correctly, and I agree with him on it. Having a enum is ideal, but no need for it to be mandatory, as other also pointed out. On Fri, Dec 3, 2010 at 4:54 PM, Eric Seidel wrote: > I'm not sure we have any examples of bool passing like that in real code. > The case I'm concerned about is not one of single argument bools: > doSoemthing(bool) > but more of multi-argument functions: > doSomething(something, bool) > I'm trying to write a rule which can be easily automated by > check-webkit-style. > It's possible we could tighten the rule further to only allow > single-argument bools where "set" is in the function name. > It sounds like most folks are in agreement. We should add a rule like this > to check-webkit-style. Sounds like Dave Levin may already have something > partial in the works. > -eric > On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa wrote: >> >> On Fri, 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. >>> 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." >> >> That rule makes sense to me. >> On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel wrote: >>> >>> Dave, I'm not sure I understand your exception. Could you give an >>> example? >> >> I think what he means is that >> bool doSomething(); >> void doSomethingElse(bool); >> and the only case we always call doSomethingElse with a return value of >> some function or with a variable: >> doSomethingElse(doSomething()); >> doSomethingElse(shouldNotDoSomethingElse); >> etc... >> and we never call it with raw true/false: >> doSomethingElse(true) >> doSomethingElse(false) >> - Ryosuke >> >> ___ >> 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 > > -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa wrote: > On Fri, 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. >> 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." > > That rule makes sense to me. > On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel wrote: >> >> Dave, I'm not sure I understand your exception. Could you give an >> example? > > I think what he means is that > bool doSomething(); > void doSomethingElse(bool); > and the only case we always call doSomethingElse with a return value of some > function or with a variable: > doSomethingElse(doSomething()); > doSomethingElse(shouldNotDoSomethingElse); > etc... > and we never call it with raw true/false: > doSomethingElse(true) > doSomethingElse(false) Out of curiosity, what do people think of doSomethingElse(/*paramName=*/true); when calling an existing function that takes a bool? Nico > - Ryosuke > > ___ > 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
Re: [webkit-dev] Bools are strictly worse than enums
I'm not sure we have any examples of bool passing like that in real code. The case I'm concerned about is not one of single argument bools: doSoemthing(bool) but more of multi-argument functions: doSomething(something, bool) I'm trying to write a rule which can be easily automated by check-webkit-style. It's possible we could tighten the rule further to only allow single-argument bools where "set" is in the function name. It sounds like most folks are in agreement. We should add a rule like this to check-webkit-style. Sounds like Dave Levin may already have something partial in the works. -eric On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa wrote: > On Fri, 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. >> >> 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." >> > > That rule makes sense to me. > > On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel wrote: > > Dave, I'm not sure I understand your exception. Could you give an example? > > > I think what he means is that > bool doSomething(); > void doSomethingElse(bool); > > and the only case we always call doSomethingElse with a return value of > some function or with a variable: > doSomethingElse(doSomething()); > doSomethingElse(shouldNotDoSomethingElse); > etc... > > and we never call it with raw true/false: > doSomethingElse(true) > doSomethingElse(false) > > - Ryosuke > > > ___ > 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
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, 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. > > 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." > That rule makes sense to me. On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel wrote: > Dave, I'm not sure I understand your exception. Could you give an example? I think what he means is that bool doSomething(); void doSomethingElse(bool); and the only case we always call doSomethingElse with a return value of some function or with a variable: doSomethingElse(doSomething()); doSomethingElse(shouldNotDoSomethingElse); etc... and we never call it with raw true/false: doSomethingElse(true) doSomethingElse(false) - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
That would be so unbelievably fantastic! On Fri, Dec 3, 2010 at 1:35 PM, David Levin wrote: > > > On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel wrote: > >> It seems to me, that using bool types for function arguments is strictly >> worse than using an enum. An enum is always clearer and can be easily >> casted to a bool if needed. >> >> doSomething(something, false); >> >> Is much less readable than: >> >> doSomething(something, AllowNetworkLoads); >> >> >> Do any C++ gurus have further information to add here? Is my (simple) >> analysis here incorrect? If not, seems we should forbid boolean values in >> multi-argument methods/constructors in our style and add checks to >> check-webkit-style >> > > I'm pretty close to being able to do this in check-webkit-style. (I was > actually working on something else. Flagging unnecessary param names "void > foo(ScriptExecutionContext* context);" because I get tired of mentioning > this in code reviews.) > > >> to prevent further introduction of these confusing callsites. >> >> -eric >> >> ___ >> 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
Re: [webkit-dev] Bools are strictly worse than enums
Dave, I'm not sure I understand your exception. Could you give an example? On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt wrote: > On Dec 3, 2010, at 3:33 PM, Darin Fisher wrote: > > On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel wrote: > >> It seems to me, that using bool types for function arguments is strictly >> worse than using an enum. An enum is always clearer and can be easily >> casted to a bool if needed. >> >> doSomething(something, false); >> >> Is much less readable than: >> >> doSomething(something, AllowNetworkLoads); >> >> >> Do any C++ gurus have further information to add here? Is my (simple) >> analysis here incorrect? If not, seems we should forbid boolean values in >> multi-argument methods/constructors in our style and add checks to >> check-webkit-style to prevent further introduction of these confusing >> callsites. >> >> -eric >> > > > I was under the impression that this was already an encouraged style in > WebKit code. At least, I really like that is makes call-sites more > self-documenting. > > > 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. > > 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." > > dave > (hy...@apple.com) > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Dec 3, 2010, at 3:33 PM, Darin Fisher wrote: > On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel wrote: > It seems to me, that using bool types for function arguments is strictly > worse than using an enum. An enum is always clearer and can be easily casted > to a bool if needed. > > doSomething(something, false); > > Is much less readable than: > > doSomething(something, AllowNetworkLoads); > > > Do any C++ gurus have further information to add here? Is my (simple) > analysis here incorrect? If not, seems we should forbid boolean values in > multi-argument methods/constructors in our style and add checks to > check-webkit-style to prevent further introduction of these confusing > callsites. > > -eric > > > I was under the impression that this was already an encouraged style in > WebKit code. At least, I really like that is makes call-sites more > self-documenting. 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. 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." dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel wrote: > It seems to me, that using bool types for function arguments is strictly > worse than using an enum. An enum is always clearer and can be easily > casted to a bool if needed. > > doSomething(something, false); > > Is much less readable than: > > doSomething(something, AllowNetworkLoads); > I agree that in general, the latter is better. Do any C++ gurus have further information to add here? > Restricting bools can limit your ability to pass results of one function as arguments to another. It is plausible to have function A return a different "enumerated boolean" type than function B takes, for example, if one type is a special-case of the other. This means you'll need to add explicit ?: ops, conditionals, or casts, all of which make me more unhappy than the original bools did. This is probably an issue in a minority of cases, but it might be reason to use "should" rather than "must" language here. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bools are strictly worse than enums
On Fri, Dec 3, 2010 at 1:28 PM, Eric Seidel wrote: > It seems to me, that using bool types for function arguments is strictly > worse than using an enum. An enum is always clearer and can be easily > casted to a bool if needed. > > doSomething(something, false); > > Is much less readable than: > > doSomething(something, AllowNetworkLoads); > > > Do any C++ gurus have further information to add here? Is my (simple) > analysis here incorrect? If not, seems we should forbid boolean values in > multi-argument methods/constructors in our style and add checks to > check-webkit-style to prevent further introduction of these confusing > callsites. > > -eric > I was under the impression that this was already an encouraged style in WebKit code. At least, I really like that is makes call-sites more self-documenting. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bools are strictly worse than enums
It seems to me, that using bool types for function arguments is strictly worse than using an enum. An enum is always clearer and can be easily casted to a bool if needed. doSomething(something, false); Is much less readable than: doSomething(something, AllowNetworkLoads); Do any C++ gurus have further information to add here? Is my (simple) analysis here incorrect? If not, seems we should forbid boolean values in multi-argument methods/constructors in our style and add checks to check-webkit-style to prevent further introduction of these confusing callsites. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
