3 ms·
I mean, this is entirely a self-inflicted problem. If you'd just use a few more words in the name, none of this would be an issue. There's nothing wrong with l
by user-the-name 6y ago
I mean, this is entirely a self-inflicted problem. If you'd just use a few more words in the name, none of this would be an issue.
There's nothing wrong with longer function names. They make code a lot easier to read.
- dmurray 6y agoYou'd prefer something like vec.construct_then_push_back(foo, bar)? I think it's reasonable that people would want a pithier name than that, for something you're going to use constantly.
- user-the-name 6y ago"f8" would be even shorter, but we don't use that, because it is more important that code is easy to read than quick to write.
- bregma 6y agoI think they mean `std::vector::construct_back_in_place()`. 200 character line widths will no longer be enough: 400 or 500 will be more realistic. Sacrifice readability for readability.
- user-the-name 6y agoHow many function calls do you put on a single line? Break those statements up!
- MauranKilom 6y agoActually, for frequently used standard library functionality, I would very much object to introducing overhead for educational purposes at every single call site. It's a tradeoff, of course, but if the user code becomes unreadable because the function names are verbose (so you constantly have to wrap lines and cut through the visual noise to see the actually meaningful part of the code), just to make sure people don't misunderstand basic functionality... that's not the tradeoff I would like.