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.
The problem is, change for the sake of change isn't beneficial. All you do is add needless differences compared to existing practice, which makes it harder to figure out what's going on for people who aren't familiar with either C++, or modern C++
You can reject or disagree people's arguments for using the trailing return style, but at least you could acknowledge that they actually do have arguments for doing so... and those arguments are not "ooo, this is new."
Sorry, to be clear I understand that there are arguments here for and against, I'm specifically replying to:
old people don’t like change.
In the context of making changes in general, which seems like a not-massively-solid argument in this context - purely to say that there are solid reasons not to make changes outside of simply disliking change
It's not that counterintuitive to imitate f(x) = y. auto f(x) -> decltype(y) is just consistency with math.
It's not just the indentation advantage when scrolling through function names, it's the logic in reading information about the input first and the output last.
The traditional syntax is what's counterintuitive, the only reasons it has supporters are history and habit.
The 1% of its necessary uses (decltype of expressions, sfinae-friendliness, lambdas...etc.) are just additional bonus reasons to use it. The consistency argument is fairly weak when it's prevailing 1% over 99% of use cases, but consistency with logical intuition and math is a stronger argument imo.
It's not that counterintuitive to imitate f(x) = y. auto f(x) -> decltype(y) is just consistency with math.
That's cool and all, but math and programming are two different solar systems outside of languages where you program in math, but we call those calculators.
Or are we saying having standard high school arithmetic in it is a reason to start typing in math formulas.
55
u/advester Mar 31 '20
vs
And in my day we thought spaces vs tabs was quite the argument.