Whonix coding style inconsistencies

[madaidan]

A few inconsistencies in the source code are slightly irking me.

Across the Whonix source code, a lot of the line wrapping is inconsistent. One line may be X characters long whilst another is Y characters, particularly when it comes to comments. What would the preferred length be?

The bracing of variables in bash code is also inconsistent. Should variables be $example or ${example}? I usually prefer to brace variables because I think it looks better and because it’s good practice but most other code doesn’t use braces.

[Patrick]

@madaidan

One line may be X characters long whilst another is Y characters, particularly when it comes to comments.

My thinking:

• If there was a pretty long code line above anyhow that gets harder to read if new line split using \, then it would be wasteful to pretend we’re enforcing an 80 characters line limit for comments.
• Sometimes finishing off a sentence in new line making it look less pretty.
• Sometimes easier to read to finish a sentence of thought then making a new line.
• Certainly don’t add new line if shell output or anything else was copied/pasted into the source code. Such as “example output for command x is:”. Better to keep at least that original because that helps to better understand the string parsing that follows below.

Related:

Kicksecure Coding Style

@madaidan

What would the preferred length be?

I am not sure. Surely we don’t need to limit ourselves to 80 characters as if we were stuck in the age of virtual terminals with maximum 80 characters line length?

Can we refer to other, existing, popular style guides?

@madaidan

The bracing of variables in bash code is also inconsistent. Should variables be $example or ${example}? I usually prefer to brace variables because I think it looks better and because it’s good practice but most other code doesn’t use braces.

Makes sense. Current style is $example for simplicity and ${example} whenever required or contributed so. Changing to ${example} could be done if there was a script or command which would change that given a file.

Automation scripts / functions already in whonix-developer-meta-files:

• loop over every Whonix package
• loop over every source file
• do something on every source file
• run git diff before running git commit

The only thing missing is changing $varname to ${varname}. Ideally test / review that this doesn’t add any breakage.

[madaidan]

@Patrick

My thinking:

• If there was a pretty long code line above anyhow that gets harder to read if new line split using \, then it would be wasteful to pretend we’re enforcing an 80 characters line limit for comments.
• Sometimes finishing off a sentence in new line making it look less pretty.
• Sometimes easier to read to finish a sentence of thought then making a new line.
• Certainly don’t add new line if shell output or anything else was copied/pasted into the source code. Such as “example output for command x is:”. Better to keep at least that original because that helps to better understand the string parsing that follows below.

What about a “soft limit” of 80 but a few extra characters would be permitted if it improves readability?

@Patrick

Surely we don’t need to limit ourselves to 80 characters as if we were stuck in the age of virtual terminals with maximum 80 characters line length?

People often have multiple windows open at the same time and aren’t using the entire width of the monitor for reading code.

@Patrick

Can we refer to other, existing, popular style guides?

Linux has something like I described above: Linux kernel coding style — The Linux Kernel documentation

"The preferred limit on the length of a single line is 80 columns.

Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information."