| Summary: | Some small modernizing tweaks to the coding style guide | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Darin Adler <darin> | ||||
| Component: | New Bugs | Assignee: | Darin Adler <darin> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | andersca, sam | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Darin Adler
2014-02-27 08:59:11 PST
Created attachment 225374 [details]
Patch
Comment on attachment 225374 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=225374&action=review > Websites/webkit.org/ChangeLog:14 > + without non-WebKit-style abbreviations and such. Use auto& instead of const auto& in for loop > + example, since that's normally preferred. Changed section title to say "zero" instead of "0". This is one part I'm not sure of. We have a lot of "const auto&" loop variables currently in the tree, and I personally like those. (In reply to comment #2) > This is one part I'm not sure of. We have a lot of "const auto&" loop variables currently in the tree, and I personally like those. The compiler will automatically propagate the const from the collection if begin/end are overloaded suitably. How critical is it to narrow the reference to read-only in cases where the access to the collection is not already read-only? Is it worth an extra keyword on every one of these for loops? Comment on attachment 225374 [details]
Patch
For now I will land with "auto&". We can change back later if we confirm that "const auto&" is preferred.
Committed r164930: <http://trac.webkit.org/changeset/164930> Comment on attachment 225374 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=225374&action=review > Websites/webkit.org/ChangeLog:17 > + over index iteration in vector iteration example and also showed use of unsigned rather than > + size_t since that is almost always what we want. Eliminated the use of PassOwnPtr in the "return Why is "unsigned rather than size_t" preferred? Shouldn't we match the type that the method / object produces? |