[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Stylistic changes and documentation.

From: Felix Salfelder
Subject: Stylistic changes and documentation.
Date: Thu, 24 Nov 2022 12:34:43 +0100

Hi there.

We expect some movement in the develop branch in the next weeks, so
maybe this is a good time to revisit style and standard.

1) auto. While generally not a good idea (obfuscates code too quickly),
        there are use cases, where auto makes code faster to type, less
        redundant and helps avoid line breaks.

        auto ptr = new TYPE(args);
        auto ptr = some_case<NEW_TYPE*>(thing);
        especially in

        if(auto ptr = dynamic_cast<NEW_TYPE*>(thing)){

2) override. Functions intended to override others should be marked as
   such. This will improve readability as well as catch typos and type
        mismatch immediately.

3) delete. It is easier to delete unwanted defaults than implementing

        class C{
           // explicit C(){ unreachable(); } // note: may be ill formed.
           explicit C() = delete;

        As a side effect, this will produce errors at compile time, not at
        run time.

4) Private data members. In some (presumably old?) code they are at the
   top of the class.  I believe they should always be at the bottom. They
   are not very interesting or insightful when looking at the interface.

5) New code must apply to style rules. Trivial style Changes in existing
   code have to be be committed seperately. We should actually do this
   sooner than later esp. in regions where changes are expected.

Do you agree with these? There are proably more. Let me know, I will add
them to [1].



reply via email to

[Prev in Thread] Current Thread [Next in Thread]