I don't contribute code to darktable often, but I do follow this list
closely and feel the need to comment on this. Take it or leave it as
you wish.
On 2/1/23 7:04 AM, Moritz Moeller wrote:
This has nothing to do with how many character fit on a line on any
display and everything with legibility.
Just because it's code doesn't mean rules discovered by typographers
and used for typesetting text for centuries do not apply. ;)
45-90 chars/line is the suggested default for body text.
The darktable source code isn't prose and isn't consumed like it. I can
all but guarantee that formatting it according to _all_ of the rules for
typesetting text and forcing people to work with it would result in a
lot of screaming.
See https://practicaltypography.com/line-length.html
From that page:
"If you plan to use indenting to distinguish sections or hierarchies
within your document, take this into account when setting up the initial
line length. You want to start with long enough lines so that the
indented parts also fall within the target range. Using fewer levels of
indentation, and smaller indents, will help."
The implication there is that, despite the dictum at the top of the
section, the characteristics of the material being set should be taken
into consideration.
There are modern languages which enforce a unified code formatting
style. Rust e.g. hast rustfmt which almost all projects run
automatically ...
Modernity doesn't really make a difference here. Rust didn't invent
bringing a formatter along with the language and it certainly didn't
introduce forced formatting for commits. I've been on projects where
that was done to the assembly code.
darktable is written in C. C is saddled with having exactly one
namespace, which means globally-declared identifiers have to be unique.
Uniqueness turns into length when the identifiers need to be
human-readable and sensibly-organized. Identifiers that run north of 20
characters aren't unusual in this code base, nor are places where they
end up in long lines. A modest expansion of the line width to make
those lines work better might not be a bad thing.
That said, in three years of using Rust and seeing Rust code in the
wild, I've never seen 100c/l ever reached because there are other
rules in rustfmt that commonly prevent this.
Most C does just fine constrained to 80. Most parts of darktable I've
browsed through probably would, too. But... In 35 years of writing C
and seeing C code in the wild, I've run into code bases where formatters
constrained to short lines made them awkward and difficult to read.
Constraining darktable's C code base to whatever length some other code
base in some other language uses as standard is dogma-driven design and
it's not helpful.
The pragmatic approach would be to find something that works for *this*
code base and *these* developers. Propose a few different line widths,
format the entire code base for each and put copies up someplace.
Anyone with an interest can spot check whatever parts of the code they
find interesting and provide feedback on readability and how usable
those widths are with the development tools. Give extra weight to the
opinions of the people who spend the most time around the source. Then
settle on a standard, apply it to the *entire* code base and stick with
it. If there are different developers in five years who have different
opinions, they can go through this exercise again.
--Mark
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
