[Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations

[Alex Afanasyev]

I don’t have a strong feeling that we need to standardize this part.  I usually prefer something similar to what Jeff showed: variable + continuation for each .append method (modified 3a/3d).  I don’t see any appealing reason to reject any of the presented styles.  I can only wish that the selected way is consistent within a single module (at least .cpp/.hpp).

—
Alex

> On Mar 11, 2015, at 4:25 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
> 
> I have no strong feelings. 3.(a) looks nice to me.  If the first ".append" is too long you could also do:
> 
> return certName
>   .append(signingIdentity)
>   .append("KEY")
>   .append(keyName.getSubName(signingIdentity.size()))
>   .append("ID-CERT")
>   .appendVersion();
> 
> 
> From: Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>>
> Date: Wednesday, March 11, 2015 at 16:17
> To: Jeff Thompson <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>>
> Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>
> Subject: Re: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations
> 
> Dear folks
> 
> Thanks JeffT for pointing out this snippet.
> I have more questions about the alignment.
> (for the example, let's assume two .append() calls cannot fit on the same line)
> 
> 
> 1. Why not align '.append' of subsequent lines (rule 3.23), given the part before it ("certName") is short?
> 
> certName.append(signingIdentity)
>         .append("KEY")
>         .append(keyName.getSubName(signingIdentity.size()))
>         .append("ID-CERT")
>         .appendVersion();
> 
> I feel this looks better than indent subsequent lines with two spaces.
> 
> 
> 2. What if "certName" is a shorter identifier?
> 
> (a)
> 
> n.append(signingIdentity)
>   .append("KEY")
>   .append(keyName.getSubName(signingIdentity.size()))
>   .append("ID-CERT")
>   .appendVersion();
> 
> (b)
> 
> n.append(signingIdentity)
>  .append("KEY")
>  .append(keyName.getSubName(signingIdentity.size()))
>  .append("ID-CERT")
>  .appendVersion();
> 
> I feel (b) looks better.
> 
> 3. Suppose there's a 'return' in the front, how should I align subsequent lines?
> 
> (a)
> 
> return certName.append(signingIdentity)
>   .append("KEY")
>   .append(keyName.getSubName(signingIdentity.size()))
>   .append("ID-CERT")
>   .appendVersion();
> 
> (b)
> 
> return certName.append(signingIdentity)
>        .append("KEY")
>        .append(keyName.getSubName(signingIdentity.size()))
>        .append("ID-CERT")
>        .appendVersion();
> 
> (c)
> 
> return certName.append(signingIdentity)
>          .append("KEY")
>          .append(keyName.getSubName(signingIdentity.size()))
>          .append("ID-CERT")
>          .appendVersion();
> (d)
> 
> return certName.append(signingIdentity)
>                .append("KEY")
>                .append(keyName.getSubName(signingIdentity.size()))
>                .append("ID-CERT")
>                .appendVersion();
> 
> I'd prefer (d).
> (a) and (c) also look nice, in case (d) would exceed column limit.
> (b) is worse than (a) and (c).
> 
> Yours, Junxiao
> 
> On Wed, Mar 11, 2015 at 4:06 PM, Thompson, Jeff <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>> wrote:
>> ndn-cxx already has plenty of code with the first option. This looks good to me. For example:
>> https://github.com/named-data/ndn-cxx/blob/34a37630a14c67309467074b448057dbf62cda65/src/security/key-chain.cpp#L338 <https://github.com/named-data/ndn-cxx/blob/34a37630a14c67309467074b448057dbf62cda65/src/security/key-chain.cpp#L338>
>> 
>> certName.append(signingIdentity)
>>   .append("KEY")
>>   .append(keyName.getSubName(signingIdentity.size()))
>>   .append("ID-CERT")
>>   .appendVersion();
>> 
>> - Jeff T
>> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150315/9d95a069/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150315/9d95a069/attachment.bin>