[postgis-devel] Code formatting digging in

Sandro Santilli strk at kbt.io
Wed Feb 28 13:50:13 PST 2018


On Wed, Feb 28, 2018 at 05:49:35PM +0000, Darafei "Komяpa" Praliaskouski wrote:
> I'm ok with doing formatting before editing of code, file by file, if that
> seems feasible on writing.

Is this a "keep f**king with formatting" position ?

> I think that thread started with people being unhappy about me doing so.

Mixing style changes with functional changes is a no-no, and changing
formatting for the sake of it you can see is a non-popular choice.

> I have two questions then:
> 
>  - do we have to blend into the style of
> https://github.com/postgis/postgis/blob/svn-trunk/extensions/address_standardizer/gamma.c#L142
> if
> editing around it, or there is an option to clean it up before?

Personal opinion: I don't care, as long as it is readable and easy for
me to keep it still readable while I edit (editorconfig helps me with
getting TABS or SPACES depending on which file I'm editing).

>  - do we follow the
> https://github.com/postgis/postgis/blob/svn-trunk/STYLE#L27, to the letter
> or to the spirit?

I think that file would need an update as there are now different styles
in different subdirs (topology has space block indents) and
"editorconfig" is not mentioned at all.

The block you're referring too is this one:

If you want to re-format a file you are working on:

 a) run astyle on it
 b) commit
 c) do your work
 d) commit
 e) if you are really finicky run astyle again
 f) commit

Apart from I'd drop "d" to avoid a non-formatted commit, the procedure
clearly only works if there's an easy way for all contributors to
"run astyle", which is currently not available unless we embed it.

--strk;


More information about the postgis-devel mailing list