[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
dummies.
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].
cheers
felix
[1] http://gnucap.org/dokuwiki/doku.php/gnucap:manual:tech:style
- Stylistic changes and documentation.,
Felix Salfelder <=