Project

General

Profile

Issue #3111

Odd code formatting

Added by Noel Kuntze 14 days ago. Updated 14 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.8.0
Resolution:

Description

The code formatting in strongSwan's source code is rather odd at times.
For example the code of the "select_signature_schemes" function in pubkey_authenticator.c1
has an odd indentation scheme for function arguments. If they are broken over several lines,
and call other functions by themselves, the second and further arguments for them are indented
much further than necessary, putting them well beyond the common 80 character limit of lines.
I think the code should be completely relinted with a linter configuration that removes those oddities.
It made the code slightly easier to read and not draw the eye of the viewer unnecessarily.

[1] https://github.com/strongswan/strongswan/blob/8d8e7a9c8b446221b16b3531f42e7ee30f6bdfa2/src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c#L151

History

#1 Updated by Tobias Brunner 14 days ago

  • Status changed from New to Feedback

For example the code of the "select_signature_schemes" function in pubkey_authenticator.c1
has an odd indentation scheme for function arguments. If they are broken over several lines,
and call other functions by themselves, the second and further arguments for them are indented
much further than necessary, putting them well beyond the common 80 character limit of lines.

Nope, we use a tab width of 4 (see ProgrammingStyle). It's just GitHub (and maybe some editors) that insist on using 8 characters. I did some experiments with .editorconfig (which GitHub interprets) about a year ago but never completed it (current state is now pushed to the whitespace branch). With that the file looks more readable on GitHub: https://github.com/strongswan/strongswan/blob/whitespace/src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c#L151

#2 Updated by Noel Kuntze 14 days ago

Thanks for pushing that. It looks good.

It's not just github doing that. It's also less. The code looks just fine in Sublime Text 3 again. It's all weird.

#3 Updated by Tobias Brunner 14 days ago

Thanks for pushing that. It looks good.

I've updated it and added some fixes too. Unfortunately, we use an indentation style for continuation lines (e.g. for function calls or declarations that span multiple lines) that is currently not supported by .editorconfig (the last tab may be replaced with 1-3 spaces to align with the previous line, see this issue for details). So we can't run eclint or similar (e.g. on Travis) to check for issues. But at least it looks better on GitHub.

It's also less.

True, I've actually set core.pager in my Git config to less --tabs=4 -S for that reason (e.g. for git diff or git log -p).

The code looks just fine in Sublime Text 3 again.

Sublime Text uses 4 as default tab size and it guesses whether to use tabs or spaces from the contents of the opened file (not always successfully).

Also available in: Atom PDF