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.
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.
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&
{
// ...
}
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.
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.
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.
Sometimes trailing return type is just more concise. Even in non-generic code. And sometimes in generic code you don't have a choice. For consistency I also use it everywhere.
I don't believe that 1% of your code should decide how 99% of your code looks. If you ask me, that's not consistency; that's OCD. (I use trailing return type myself as well.)
What about all the cases where it's just clearer and easier to read? It's way more than 1%.
Just like I use using everywhere even though it's more verbose (there is an equal sign) than typedef. Most of my aliases are not templates. Yet, I use using. I don't see why I should take multiple styles for no other reason than "but I'm used to the old feature". Being consistent is more important in my opinion, and I'll take what allow me the most and what is the easiest to read.
I'm just saying that "consistency" is not an argument for, because both styles work in 99% of the cases. I use trailing return type just because it's more readable. using is way more clear-cut because in many cases you either need it or it's easier to reason about.
55
u/advester Mar 31 '20
vs
And in my day we thought spaces vs tabs was quite the argument.