Looking at that code I’m shocked that Postgres allows two-liner if statements without a matching {} (I’m sure someone pedantically will point out that I’m using the wrong terminology or that it was actually several lines of conditionals).

This practice is very bug prone, and has lead to high profile failures like goto fail

▲

yencabulator 2 days ago | parent | next [-]

The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly).

That particular git repository has history imported from 1996 onward, but Postgres was a very established project by then: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.

▲

azinman2 2 days ago | parent [-]

Except this was new code.

▲

yencabulator 2 days ago | parent [-]

Generally, large C projects have their own style that is followed whether the code is new or not.

▲

azinman2 2 days ago | parent [-]

And thus it’s surprising to me they haven’t changed their style moving forward when it’s known that this is error prone.

	▲	yencabulator 2 days ago \| parent [-]
		Large stable projects are very much wary of wide-scale changes their codebase. What they have is tested working by decades in production. Especially with C where tooling is brittle. Let me put this way: If you submit a code prettifying patch to the Linux kernel, it will not be accepted. The risks aren't worth it. The only real way forward is full migration away from C, for which a better scope is a separate project.

▲

fweimer 2 days ago | parent | prev | next [-]

These days, there are compiler diagnostics for that. There's also a pgindent tool, which will align the visual presentation of the code with its syntactic structure.

▲

machinate 2 days ago | parent | prev [-]

What issue are you taking with the code? Line breaks in the condition?

Presumably the last if statement in the diff.

▲

azinman2 2 days ago | parent [-]

There aren’t {} brackets after the if

▲

machinate 2 days ago | parent [-]

Are you saying they should always be present? Or only when the condition takes multiple lines; i.e. do you take issue with the ifs in zone_name_pref too?

Personally I think the indentation does a good enough job here.

	▲	azinman2 2 days ago \| parent [-]
		Yes I’m saying they should always be present. It is known to otherwise be error prone, which is why new c-like languages do not permit this (eg go) nor do many style guides (https://google.github.io/styleguide/cppguide.html#Formatting...)