Re: INN indentation

On 19/09/2021 16:43, Russ Allbery wrote:
> Richard Kettlewell <[email protected]> writes:
> 
>> However the reality is slightly more complicated: many files use tabs
>> and spaces interchangeably, apparently with an assumption that the tab
>> character represents 8 spaces, despite the coding style saying indent is
>> 4 spaces.
> 
> The tabs are all legacy; I was removing them when I did a comprehensive
> revisit of a file back when I was rewriting more of the code and adding
> tests, but didn't get to most of them.
> 
> My preference is to never write a tab to disk in source code.  I think it
> should be a purely in-editor command represented by spaces on disk.

In that case I will not feel guilty about any tab->space conversions in 
any future PRs I submit. l-)

>> Would it be possible to adopt an indent rule in which either tabs match
>> the indent depth, or tabs are not used at all, and reformat the source
>> code accordingly?
> 
> For my personal projects, I've started using clang-format to just reformat
> all of the source code and keep it consistently formatted.  It requires
> some work up-front to mark some code blocks to not reformat, because it
> messes up a lot of code that's carefully laid out to make it easier to
> read, but once you're done you can then stop thinking about it.  It's very
> similar to using black for Python.  One can then add it to the tests and
> reject malformatted diffs, or even provide a Git hook to automatically fix
> formatting.

I do the same in my personal projects.

I would love to see an agreed .clang-format as part of INN, and again, 
don't care much what the format is, as long as it's completely 
uncontroversial to use it.

At work we have agreed a .clang-format. Nobody is required to reformat 
anything (and most developers have better things to do) but if you do 
reformat, that's the format you must use.

ttfn/rjk