[PATCH] Some code improvements (no functional change)
Duncan P. N. Exon Smith
dexonsmith at apple.com
Tue Apr 29 10:29:16 PDT 2014
On 2014-Apr-17, at 2:49, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote:
> Thank you Duncan.
>
>> I don't think the code churn of the other include guards is worth it.
>> They're private headers that work together as is, and haven't been
>> modified since the original commit.
>
> To be fair, regutils.h had been modified once since then (r81114); but is
> there any reason not to add the guards?
There are cases were header guards are incorrect (break functionality),
but I doubt this is one of them. Nevertheless, I don't see any reason for
code churn for the sake of churn.
>> When the function is local to a file, SwapValue() is clear enough, but
>> once it's API: how do the names SwapValue() and SwapByteOrder() match
>> up together?
>
> I agree that SwapValue() is not a very good name to begin with.
I don't think the name is a big problem when it's locally defined.
> Would it be reasonable if we name both SwapByteOrder() -- it's difficult to
> describe their purpose in any other way -- and make the in-place function
> take a pointer, instead of a reference?
Pointer is the wrong API: it implies having to check for null.
> That way, it would be more evident from the call site whether the function
> operates on the argument or takes a copy.
Frankly, this is a one-liner wrapper defined locally in two places. I don't
think this is worth doing.
However, if you're determined (or are planning to use this elsewhere),
`SwapByteOrderInPlace()` would be fine by me.
If it's in a public header, it should be declared `inline`, not `static`.
More information about the llvm-commits
mailing list