Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: INN indentation (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Sep 2021 17:33:26 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 133, Issue 13
********************************************
