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

Some questions about the Coding Guidlines #19

Open
theZiz opened this issue Dec 16, 2016 · 7 comments
Open

Some questions about the Coding Guidlines #19

theZiz opened this issue Dec 16, 2016 · 7 comments

Comments

@theZiz
Copy link
Member

theZiz commented Dec 16, 2016

I have some questions and unclearities about the coding guidlines.

no code alignment (only indention)
What does this mean? No code like this

int result = my_fancy_function( parameter1, parameter2, parameter3, parameter4,
                                parameter5, parameter6, parameter7 );

but this

int result = my_fancy_function( parameter1, parameter2, parameter3, parameter4,
    parameter5, parameter6, parameter7 );

?

@ax3l:

int result = my_fancy_function(
    parameter1,
    parameter2,
    // ...
    parameter7
);

code inside the deepest namespace is indented
This is missleading. What if I have such a code:

namespace foo
{
namespace traits
{
    template<
        typename T_Type
    >
    struct Bar;
} // namesspace traits

template<
    typename T_Type
>
void bar( T_Type t )
{
    traits::Bar::bar( t );
}

} // namespace foo

It fulfills the rule, but is this really the intended behaviour?

Template Class / Struct and Type Definitions
There is no explicit rule, that the opening tocken of a template parameter needs to be bing to the template keyword, such that this is forbidden:

template <
    T_Keks
>

although it makes sense in the general context. However especially with these defintions over more than one line, it it harder to spot template< than template <. The same is in fact also true for function and method definitions, but ( is slimer and therefore better to spot, so the effect is not so strong.
Is it really that important to forbid these spaces?

@ax3l
Copy link
Member

ax3l commented Dec 16, 2016

eaasy :)

no code alignment (only indention)

no, >1 argument have all one line per argument

code inside the deepest namespace is indented

yes it is! often seen in traits and details scopes. but actually: the first level of non-namespace objects in indented from its namespace if that is still up to date @psychocoderHPC .

namespace foo
{
namespace traits
{
    template<
        typename T_Type
    >
    struct Bar;
} // namesspace traits

    void a();

    template<
        typename T_Type
    >
    void bar( T_Type t )
    {
        traits::Bar::bar( t );
    }

} // namespace foo

Template Class / Struct and Type Definitions

should be template< ... as with any opening bracket that belongs to it's opening "object".

@j-stephan
Copy link
Collaborator

j-stephan commented Sep 16, 2020

Hijacking this old issue: I am currently working on a proposal to overhaul these coding guidelines. I see that we are referencing C++98 in some cases - do we still need to consider this quite ancient standard? Or can I remove those lines? @psychocoderHPC

@bernhardmgruber
Copy link
Collaborator

Thank you for proposing an overhaul!

IMO i would throw all the coding guidelines away that can be automated by clang-format. Then add a clang-format file and maybe annotate some of the options why they have been chosen this way.

@sbastrakov
Copy link
Member

I think the suggestion of @bernhardmgruber is great, as that would keep everything at a single place (clang-format file), and so only one place needs to be updated/extended

@j-stephan
Copy link
Collaborator

j-stephan commented Sep 16, 2020

clang-format is done but we will need clang-tidy as well to enforce all of our standards. Working on that now. I will upload both .clang-format and .clang-tidy once I'm done.

@psychocoderHPC
Copy link
Member

Hijacking this old issue: I am currently working on a proposal to overhaul these coding guidelines. I see that we are referencing C++98 in some cases - do we still need to consider this quite ancient standard? Or can I remove those lines? @psychocoderHPC

No C++98 is IMO not ised anymore. We can focus on C++14 and newer.

@sbastrakov
Copy link
Member

I agree, C++14 should be the minimal standard.

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

No branches or pull requests

6 participants