Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coding style. #19

Open
LucHermitte opened this issue Aug 1, 2018 · 4 comments
Open

Coding style. #19

LucHermitte opened this issue Aug 1, 2018 · 4 comments

Comments

@LucHermitte
Copy link

I haven't seen a document that specifies the coding style.

While clang-format can be used to enforce where token are written, it doesn't take care of:

  • naming conventions. On the subject, I'd advise against UpperCamelCase for function names as sometimes we'll need to have functions names in lower caps in order to take advantage of the hooks left opened in the standard library though the exploitation of the Argument Dependent Lookup: see for instance T::begin() and T::end() that can be exploited to have for range loops, T::swap() that is automatically used by some algorithms and so on. We cannot take advantage of that and have function names starting with capital letters.

  • style to initialize variables:

    // old syntax, à la assign
    T v = expr;
    // old syntax, object style
    T v(expr1, expr2);
    // AAA
    auto v = expr;
    auto v =T{expr1, exp2};
    // New uniform syntax
    T v{}
    T v{expr1,expr2};

    Seeing the old and the new uniform syntax used indifferently is odd.

  • Whether everything should be specified, or whether the rule of 0 or 5 (or variants like the rule of all or nothing) are used -- I'd vote for the rule of all or nothing, it's less noisy.

  • And probably more I haven't though about.

@savmickael
Copy link
Contributor

Can you provide please a document which define the coding style to apply at sirius.

@LucHermitte
Copy link
Author

@savmickael . Who do you mean by "you"?

If I were to provide such a document, I'd be likely to pass on choices which are not the one that have been made. For instance, for technical reasons I disagree with the use of capital letters as the first letter of functions which has been obviously made here, and now it's a little bit to late for that and identifiers more friendly with one letter words and acronyms.

@savmickael
Copy link
Contributor

you = @LucHermitte
can you please define a proposition for coding style and we will evaluate the cost to follow them.

@LucHermitte
Copy link
Author

I don't know when I will have the time to provide a serious document. Also, there is the question of what it shall convert (just style, non stylistic idioms)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants