Fix inconsistent use of hard and soft tabs
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 1.2k
- Forks
- 467
- PR merge metrics
- No merged PRs in 30d
Description
The OpenVPN 3 codebase seems to use the GNU coding style as far as I can best see from the list of common indentation styles on wikipedia. I don't want to start a debate on which style is best, the best thing is consistency.
However there is a key issue throughout the code base with regards to spaces and hard tab characters, where four groups of 2-space tabs get grouped into a single hard tab. Admittedly this is done consitently from what I have seen, but I was wondering why this is the case.
To illustrate how this can be inconvenient, below I have quoted some code from OpenVPN 3 with >>------ to denote a hard tab and >~ to denote a soft tab:
openvpn/tun/builder/client.hpp:123:
>~>~public:
>~>~>~virtual void tun_start(const OptionList& opt, TransportClient& transcli, CryptoDCSettings&) override
>~>~>~{
>--------if (!impl)
>-------->~{
>-------->~>~halt = false;
>-------->~>~if (config->tun_persist)
>-------->~>~>~tun_persist = config->tun_persist; // long-term persistent
>-------->~>~else
>-------->~>~>~tun_persist.reset(new TunPersist(false, config->retain_sd, config->builder)); // short-term
>-------->~>~try {
>-------->~>~>~int sd = -1;
>-------->~>~>~const IP::Addr server_addr = transcli.server_endpoint_addr();
>-------->~>~>~// Check if persisted tun session matches properties of to-be-created session
>-------->~>~>~if (tun_persist->use_persisted_tun(server_addr, config->tun_prop, opt))
>-------->--------{
>-------->-------->~sd = tun_persist->obj();
// .... and so on
Now when your editor is set to use 8 space hard tabs, this looks fine (as indeed it does on the github code viewer):

However some editors may not have this set as their default hard tab width, or indeed may auto-detect the tab width based on the spaces. For example, VS Code which I have been developing in lately seems to generally pick up OpenVPN 3 source files as 4 space tabs, and thus renders the code as such:

As you can see, this makes the code much more difficult to read, as heavily indented code gets brought in by virtue of the hard tabs not being spaced out enough. Obviously this very small example might not look too bad given that you have just seen the code how it is supposed to look, but when going through the entire code base on different occasions on editors on different machines, this becomes very fatiguing.
This has been a problem for me when working with OpenVPN in different editors, and I cannot see any documentation or style guide as to why OpenVPN 3 chooses to convert 8 spaces into tabs, so if anyone could elaborate on this that would be great.
The only reason I could fathom for this is perhaps very minor file size space savings, but this is an extremely moot point on modern hardware, and if we're supporting old hardware then I should imagine the code base should be compliant to 80 character lines which it is now. In any case unless I am missing something, in my opinion this is more of a nuiscance than it is good.
I'm happy to provide a pull request that expands hard tabs into soft tabs to fix this issue, but as this is usually quite a devisive topic, I am opening this issue for discussion here first.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with openvpn/tun/builder/client.hpp around line 123 and inspect how hard and soft tabs are used across the C++ codebase. Before changing files, resolve the unresolved style discussion and identify the repository-wide convention to apply. Done would require consistent indentation throughout the affected codebase, with the result checked in editors using different tab widths.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- developer-experience, tooling
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100