Re: Synchronize with imath upstream
От | Andres Freund |
---|---|
Тема | Re: Synchronize with imath upstream |
Дата | |
Msg-id | 20190206164919.qmfsxic5ykyr44ec@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Synchronize with imath upstream (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, On 2019-02-06 10:15:24 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On February 6, 2019 5:17:50 AM GMT+05:30, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > >> I'm -1 for this myself. I think there are a few places that could > >> benefit from it, but my fear is that many *more* places would get > >> worse. > > > Because of imported code like ryu and imath? And because it can make code considerably better when used judiciously. > > I don't object to keeping imported code in a form that matches upstream > as best we can. (Should we also exclude such files from pgindent'ing?) I think pgindenting doesn't matter as much, as that's an automated change. But as pgindent doesn't fix the position of declarations, that's a significant manual process. > But changing conventions for our own code is an entirely different matter. > In this case, I think that having some places use it while the bulk of > the code doesn't is just a bad idea from a stylistic-consistency > standpoint. It's pretty much the same reason why we still aren't allowing > // comments --- there's no toolchain-based reason not to, but a mishmash of > comment styles would be ugly and hard to read. Consistency surely has value, but it shouldn't block making use of new things that become available. I don't feel extremely strongly about allowing declarations after statements in C (while it's obviously crucial for C++), but I do think it can be a noticably easier to reason about the values of variables if they're declared closer to use, and it's easier to make sure that a variable hasn't been used elsewhere that way. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: