On 16 July 2017 at 21:39, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> Le 16/07/2017 à 21:34, Kornel Benko a écrit :
>
>> If not now, then probably never. There is no optimal start, except
>> at start of a project.
>>
>
> Not necessarily. We do not have much spare time to do it right, and this
> kind of thing needs to be correct on first run.
>

I'm not sure what you mean here.

Regarding formatting choices, I don't believe they have to be correct on
the first run. Or rather, I don't think they have to be "complete" on the
first run. You _do_ want to avoid large sets of changes that you later
revert. But I don't see it as a big drawback to e.g. initially use
clang-format without reformatting very long lines (we currently have >3500
lines that exceed 80 characters). At a later stage, we could then modify
the formatting configuration to get rid of long lines, or just do it
manually. Or leave them.


> We can discuss this in the 2.4 cycle, even if we decide to apply it only
> at the end of the cycle. Making sure that the style we choose can be
> obtained with everyone editor of choice is not a small affair.
>

Could you expand on the editor aspect?

I'm used to invoking clang-format from within Emacs on either the entire
buffer or on a specific region. Basically using clang-format has changed
how I code. These days while writing I've  stopped caring about whitespace
formatting. Instead I intermittently I do 'clang-format-buffer' to make it
pretty, e.g. before reviewing what I've done and definitely before commits.
I know people map some TAB-shortcut to invoke 'clang-format-region' easily.

I also know there's integration for clang-format for at least Emacs, Vim,
BBEdit, Visual Studio, XCode and Atom. Clang-format can of course also be
invoked from the command line. And it can be applied using e.g. 'git
clang-format' on only the parts that are being committed.

However, I'm _not_ expecting that most developers have to use clang-format.
Or even that they will...  If developers that regularly commit were to
start using it that'd be great.

I hope the info above helped.
/Christian

PS.
Note: I could create a CI job that warns if we start getting a lot of bad
formatting in commits. Or if you want to be tyrannical (not my
recommendation), you can have a pre-commit hook.




>
> JMarc
>
>

Reply via email to