You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Alexander Rukletsov (JIRA)" <ji...@apache.org> on 2015/04/15 15:47:59 UTC

[jira] [Commented] (MESOS-2618) Update C++ style guide on function definition / invocation formatting.

    [ https://issues.apache.org/jira/browse/MESOS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496191#comment-14496191 ] 

Alexander Rukletsov commented on MESOS-2618:
--------------------------------------------

For simplicity and with automation in mind, I would suggest we have just *one* possible option, which is enforced by {{clang-format}}. I do not really care which one, but I feel #4 (the first one in your example) is most general.

> Update C++ style guide on function definition / invocation formatting. 
> -----------------------------------------------------------------------
>
>                 Key: MESOS-2618
>                 URL: https://issues.apache.org/jira/browse/MESOS-2618
>             Project: Mesos
>          Issue Type: Documentation
>            Reporter: Till Toenshoff
>            Priority: Minor
>
> Our style guide currently suggests two options for cases of function definitions / invocations that do not fit into a single line even when breaking after the opening argument bracket;
> Fixed leading indention (4 spaces);
> {noformat}
> // 4: OK.  
> allocator->resourcesRecovered(  
>     frameworkId,  
>     slaveId,  
>     resources,  
>     filters);
> {noformat}
> Variable leading indention;
> {noformat}
> // 3: In this case, 3 is OK.  
> foobar(someArgument,  
>        someOtherArgument,  
>        theLastArgument);
> {noformat}
> There is a counter-case mentioned as for the latter; 
> {noformat}
> // 3: Don't use in this case due to "jaggedness".
> allocator->resourcesRecovered(frameworkId,  
>                               slaveId,  
>                               resources,  
>                               filters);
> {noformat}
> The problem here seems to be that the counter-case might not be well defined  on when it applies.
> We might want to consider...
> A. removing the variable leading option entirely
> B. define the exact limits on when "jaggedness" applies



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)