On 01.02.23 23:04, Mark Feit wrote:
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.
Dito. Let me just clarify some perceived misunderstandings re. my
previous comments. :)
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.
That's sad and if it were true I'd consider it rather as an indicator of
what could improved than a counter argument to what I said.
Google 'code as prose'. ;)
A great example is the source to the 'Physically Based Rendering' book(s).
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. [...]
I agree, this is important.
A good code formatter will have option to make sure that foremost the
part of the line after the indentation counts towards the line length
and the indentation either not at all or by some some function of its width.
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 don't recall saying it did in either instance so I'm not sure why you
mentioned this.
Nor what difference to the validity of what I said it would make in
regards of whether language X or Y was first or shipped a formatter as
part of the default toolchain (which is pretty much non-existent for C/C++).
Formatting for comments is off by default in rustfmt btw.
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.
I think Rust and C are very comparable in this regard indeed. After
almost 35 years of C, 25 of C++ and three of Rust I feel eligible to be
opinionated here. :)
Especially since Rust encourages heavy code reuse through crates
('libs') and it is common practice to not omit the namespace when using
such imported functions/types/methods.
I.e. the 'identifiers may be somewhat long' issue is not uncommon in
Rust code as well.
The pragmatic approach would be to find something that works for *this*
code base and *these* developers.
I didn't mean to suggest anything else. I was merely pointing out that
the reasoning Matthias used is flawed.
As I am a lurker on this list and do not have to touch C code, from
darktable or otherwise, at all or very often any more, I better shut up
now. :]
Beers,
.mm
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
