On Mon, Aug 26, 2024 at 10:49 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Jun 19, 2024 at 2:21 PM Melanie Plageman > > <melanieplage...@gmail.com> wrote: > >> If we want to make it possible to use no tools and only manually grep > >> for struct members, that means we can never reuse struct member names. > >> Across a project of our size, that seems like a very serious > >> restriction. Adding prefixes in struct members makes it harder to read > >> code -- both because it makes the names longer and because people are > >> more prone to abbreviate the meaningful parts of the struct member > >> name to make the whole name shorter. > > > I don't think we should go so far as to never reuse a structure member > > name. But I also do use 'git grep' a lot to find stuff, and I don't > > appreciate it when somebody names a key piece of machinery 'x' or 'n' > > or something, especially when references to that thing could > > reasonably occur almost anywhere in the source code. So if somebody is > > creating a struct whose names are fairly generic and reasonably short, > > I like the idea of using a prefix for those names. If the structure > > members are things like that_thing_i_stored_behind_the_fridge (which > > is long) or cytokine (which is non-generic) then they're greppable > > anyway and it doesn't really matter. But surely changing something > > like rs_flags to just flags is just making everyone's life harder: > > I'm with Robert here: I care quite a lot about the greppability of > field names. I'm not arguing for prefixes everywhere, but I don't > think we should strip out prefixes we've already created, especially > if the result will be to have extremely generic field names.
Okay, got it -- folks like the prefixes. I'm picking this patch set back up again after a long pause and I will restore all prefixes. What does the rs_* in the HeapScanDescData stand for, though? - Melanie
