Update help in SkFlags.

Update help in SkFlags.

Print the short name in addition to the standard name.

Allow an option for getting help for a specific command.

Committed: https://code.google.com/p/skia/source/detail?r=8273

[borenet, 2013-03-20 18:45:28]

LGTM

https://codereview.chromium.org/12411007/diff/1003/tools/SkFlags.cpp
File tools/SkFlags.cpp (right):

https://codereview.chromium.org/12411007/diff/1003/tools/SkFlags.cpp#newcode106
tools/SkFlags.cpp:106: || flag->shortName().equals(helpFlags[k])) {
Nit: I find it more readable to have the || on the line above, so that the
conditions are aligned.  Up to you.

[scroggo, 2013-03-20 18:59:44]

https://codereview.chromium.org/12411007/diff/1003/tools/SkFlags.cpp
File tools/SkFlags.cpp (right):

https://codereview.chromium.org/12411007/diff/1003/tools/SkFlags.cpp#newcode106
tools/SkFlags.cpp:106: || flag->shortName().equals(helpFlags[k])) {
On 2013/03/20 18:45:28, borenet wrote:
> Nit: I find it more readable to have the || on the line above, so that the
> conditions are aligned.  Up to you.

I was following the Java style Android used, since our style guide doesn't offer
any guidance. Truly I don't like either option, because now the second line
lines up with code inside the block. bungeman@ had a solution I liked where he
put the brace on the next line like so:

if (long_condition1
    && long_condition)
{
    statement;
}

Technically it's against the style guide, but it does make it clear where the
conditions are and where the statements are. I'm curious how other styles which
keep the brace on the same line as the condition handle this problem.

Anyway, I fixed it, so now at least one of us is happy.

[scroggo, 2013-03-20 19:50:52]

Committed patchset #3 manually as r8273 (presubmit successful).