azure-sdk-for-c: [BUG] .clang_format pointer alignment

@sergey-shandar , @danewalton: are we good with closing on left alignment?

I personally feel very good about left alignment, like the middle alignment, and don’t like right alignment. I understand that there is no killer argument for either one, or, at least, I think I won’t be able to bring any more arguments to the discussion, other than I brought above, so if you are not convinced with what you read above, I probably won’t be able to shift your opinion. Realistically, it is not likely we will run into a real issue with either one. But I also understand the importance of liking the pointer style in the code that you write. Given all that, I am personally fine to go with the popular vote for pointer alignment, even though I’d cringe a bit if I’d have to use right alignment.

Note: in Azure SDK code we almost always use const before a variable/parameter name. So most of our code looks like this

int * const p = ...; // middle
int *const p = …; // right
int* const p = …; // left

Instead of like this

int * p = ...; // middle
int *p = …; // right
int* p = …; // left

And we don’t plan to give up const safety for left-right-middle alignment 😃 So I’m ok with any alignment, if int * const p looks good in this alignment 😉

@antkmsft, middle pointer is a terrible compromise, IMO. 😃 Looking at the boost code:

template<class T, class U> shared_ptr<T> reinterpret_pointer_cast( shared_ptr<U> const & r ) BOOST_SP_NOEXCEPT
{
    (void) reinterpret_cast< T* >( static_cast< U* >( 0 ) );

    typedef typename shared_ptr<T>::element_type E;

    E * p = reinterpret_cast< E* >( r.get() );
    return shared_ptr<T>( r, p );
}

Few counter arguments:

• As you said, they are not consistent: T* and U* on the casts do not follow the rule.
• Spaces on each side of the * or & make them look like operators. For example, at my first sight of the line below, I though we were multiplying E * p:

E * p = reinterpret_cast< E* >( r.get() );

Same happens when I look at the ‘&’ between spaces. It looks like we are doing a bitwise operation.

I do not have preferences between left or right. I understand personal preferences of people liking either one. But compromising for a third option that almost no one in the world uses it (except Boost), just creates a third problem IMO.

From our side, we will not follow the middle pointer if this is the proposal of the guideline. So, consider that as my exception request. 😃

BTW, we had closed on that exact question during one of our meetings with consensus, even if it was a compromise for some people. So, to be honest, I do not know how this got into the clang file, since it is against what we decided as a guideline decision.

Completely agree with the { on the new line. I’m 99% sure the rest of the IoT SDK team would agree as that’s what we currently do. As for the pointer alignment, it’s not a hill I’m willing to die on but I will be cringing for a while when autoformat does it’s thing.