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

Thompson, Jeff jefft0 at remap.UCLA.EDU
Wed Mar 11 16:25:47 PDT 2015


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


certName.append(signingIdentity)

  .append("KEY")

  .append(keyName.getSubName(signingIdentity.size()))

  .append("ID-CERT")

  .appendVersion();

- Jeff T

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150311/afee7fce/attachment.html>


More information about the Nfd-dev mailing list