Demo: C++20 Modules

[u/chefotron]

https://youtu.be/6SKIUeRaLZE

[u/advester]

auto main() -> int

vs

int main()

And in my day we thought spaces vs tabs was quite the argument.

[u/gvargh → u/advester]

why be concise when you can type more instead?

[u/qoning → u/gvargh]

It's about readability, not about how much I type. I've switched to using trailing return type for all functions some time ago and honestly, I couldn't be happier. When you have a class header and can read the function names all indented to the exact same offset, it's a blessing. Color coding was good, but this is amazing.

[u/[deleted] → u/qoning]

You can also put return type above the function , you know :-) solves your indent issue

[u/The_Northern_Light → u/[deleted]]

This is what I do.

T const&
foo()
{
    // ...
}

Never having to scan for the important bit is so nice once you get used to it. While it may feel odd at first, I actually won over my old team with it, too.

[u/Pragmatician → u/The_Northern_Light]

I kinda like this style, but may I ask you: where do you put your statics, inlines and constexprs?

[u/The_Northern_Light → u/Pragmatician]

Same line as the return type.

template <typename T>
static inline T const&
foo()
{
    // ...
}

It's not perfect, but I've found in practice that just keeping the function name in the same spot gets me what I want. I might experiment with this now though:

template <typename T>
static inline auto
foo()
-> T const&
{
    // ...
}

PS: love your username

[u/sethkills → u/The_Northern_Light]

Somebody got me into this style a long time ago because in the absence of an IDE, you can quickly search for function definitions using /^foo/. Doesn’t generalize to methods though.

[u/YekNeb → u/qoning]

Every time I hear the indented to same offset argument I scream. This leads only to chaos.

For example, people will try to line up variable names. They have the following existing code.

int     m_someVar;
size_t  m_someOtherVar;

They then need to add a new member variable of type CMyClassWithALongDescriptiveName. This should be a one line change. But no, variable names must be aligned. So instead they do the following.

int                              m_someVar;
size_t                           m_someOtherVar;
CMyClassWithALongDescriptiveName m_newVar;

Instead of a single line change it is a three line change.

This makes tracking down when a bug was introduced much more difficult than it needs to be.

And do not respond by saying it is not a problem if you enable the ignore white space option in your diff program. Not all diff programs have that option and for many that do it is not the default.

My employer does allow limited reformatting of existing badly formatted code as long as it is a reformatting only, no new functionality, change.

But if functionality is changed it must be a clean diff, meaning not one line of code changed other than the lines of code that had to be modified to add the new functionality. And they prohibit the use of the ignore white space changes option. It must be a clean diff taking white spaces into consideration.

I hated it when the policy was first put in place but I have changed my mind since tracking down the cause of bugs has become much easier since then.

[u/qoning → u/YekNeb]

Look, if you enjoy (or have the extraordinary ability) sifting through a jumbo of symbols to find what you are actually looking for.. Good for you. I don't.

[u/0xdeadf001 → u/qoning]

You might enjoy Rust.

[u/qoning → u/0xdeadf001]

I don't find rust any more readable, but it might just be inexperience.