On Wednesday 2014-05-28 21:03 -0700, Nicholas Nethercote wrote:
> > static T inc(T& aPtr) { return IntrinsicAddSub<T>::add(aPtr, 1); }
> > static T dec(T& aPtr) { return IntrinsicAddSub<T>::sub(aPtr, 1); }
>
> > static T or_( T& aPtr, T aVal) { return __sync_fetch_and_or(&aPtr, aVal); }
> > static T xor_(T& aPtr, T aVal) { return __sync_fetch_and_xor(&aPtr, aVal); }
> > static T and_(T& aPtr, T aVal) { return __sync_fetch_and_and(&aPtr, aVal); }
>
> > static ValueType inc(ValueType& aPtr) { return add(aPtr, 1); }
> > static ValueType dec(ValueType& aPtr) { return sub(aPtr, 1); }
>
> When it comes to questions of style, IMO clarity should trump almost
> everything else, and spotting typos in functions like this is *much*
> harder when they're multi-line.
>
> Furthermore, one-liners like this are actually pretty common, and
> paving the cowpaths is often a good thing to do.
I'd be happy for this to be allowed; I've used this style quite a
bit, for similar reasons (clarity and density).
I also like a similar two-line style for code that doesn't fit on
one line, as in:
bool WidthDependsOnContainer() const
{ return WidthCoordDependsOnContainer(mWidth); }
bool MinWidthDependsOnContainer() const
{ return WidthCoordDependsOnContainer(mMinWidth); }
bool MaxWidthDependsOnContainer() const
{ return WidthCoordDependsOnContainer(mMaxWidth); }
from
http://hg.mozilla.org/mozilla-central/file/9506880e4879/layout/style/nsStyleStruct.h#l1321
but I think that variant may be less widely used.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
