> On May 3, 2021, at 11:23 AM, Blake Bender <bbl...@vmware.com> wrote: > > My $0.02 on these: > > Things I'd like to see us conform to Google style on: > * I'd be happy to move to C++ 17
This is likely an ABI change and certainly moves the minimum runtime library. The latter might be hard in a minor release. > * Would also be happy to remove forward declarations. "I'm not a critic, but > I know what I hate," as it were, and I hate forward declarations. Yeah, the stance in Google C++ is don’t unless you really have to. We are more we do because we have include problems and it takes forever to build otherwise. We don’t use forwards in the public API though. > * I would be very pleased to remove all the macros from our code. I've been > bitten more than once in the past while debugging or refactoring our code, > because of ill-formed macros. There is no way to get rid of all of them. Our stance has been don’t do macros unless required, like platform/compiler specific attributes. As you find macros for just constants you should replace those. A lot of the large macros, like the old Cacheable stuff have been replaced with templates. There are only a few public macros, all of which are prefixed with GEODE. > Google things I disagree with: > * I don't like exceptions, but I don't even want to think about the amount of > effort required to remove them from the codebase is, IMO, unreasonably high. > Keep the exceptions, most of the time they're used pretty judiciously. Yeah, no way we can change this. > * I really, really, *really* (really? Yes, really!) hate anything resembling > Hungarian prefix notation, and have permanent scars from decades of reading > it in Windows code. Please don't ask me to put a random 'k' in from of my > enums - ick. I am on board with dropping the k if we want to diverge more from Google. > One other note: in the past, we've had conversations about "style only" pull > requests to fix some of these things, and the guidance we ended up with has > been to only fix this sort of thing while you're in the code working on a fix > or a feature. I, for one, would welcome some PRs that just, say, renamed a > ton of member variables to replace "m_" prefix with a simple trailing "_", > perhaps fixed some of the more egregious and weird abbreviations, etc. My > preference for bug fixes and feature work is that all of the code changes be > focused on stuff that's relevant to the fix/feature, and mixing it with > random style guide refactoring, I feel, muddies the waters for future > maintainers. I don’t know where that idea that you can’t do style only changes came from. Do it. I suggest we just either have a format only JIRA or don’t require a JIRA for format only. Filing JIRAs for formatting changes is just noise. -Jake
