rjk at terraraq.uk
Mon Sep 20 16:33:26 UTC 2021
On 19/09/2021 16:43, Russ Allbery wrote:
> Richard Kettlewell <rjk at terraraq.uk> 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
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.
More information about the inn-workers