Re: [dev] [dwm] [patch] config.o

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Mon, 16 May 2016 07:24:24 +0200

Hi Connor,

On 14 May 2016 at 17:24, Connor Lane Smith <cls_AT_lubutu.com> wrote:
> Attached is a dwm patch that pulls out all of the key and button
> handlers, and all of the layouts, into a new file called config.c,
> replacing config.h. The idea is that it makes it clearer what is dwm
> proper and what is just a part of the default config.
>
> I've sat on this patch for about half a year, and I've still not made
> my mind up as to whether it's a good idea or not. But I thought I
> might as well post it on here anyway.

I don't like this approach for various reasons.

First of all the decision to reduce dwm into the code not containing
key, button, focus and layouting algorithms and inventing a new
"config.c" containing all this looks very arbitrary to me. One could
argue that the affected code portions you put into config.c have been
referenced in the vanilla config.h, but conceptually pure dwm makes no
sense without key, button, focus and layouting algorithms to me.

Second this approach breaks the config.h idea pretty much. It would
make "configuring" dwm a lot harder. The idea behind config.h is to
only define data structures that later on influence the algorithms in
one way or another. One doesn't need to understand the actual
algorithms in order to "configure" dwm, or getting distracted due to
lot's of code in a config.c file. After all, config.h is also pretty
much widespread among suckless programs, hence breaking it would make
it conceptually harder to follow.
(Of course some patch contributors have taken this approach further
and inject some local functions into config.h. As long if those things
remain exceptions I see this as acceptable. However I would never
change vanilla dwm to contain functions in config.h files.)

Third and foremost all suckless code I contributed followed a very
basic rule and I still believe this is the right thing. It is the rule
that _all_ code of a certain program should belong into a _single_
file with main at the end. The only exception I do accept here is, if
one inherits code copies from library's (like util.{c,h}, drw.{c,h})
that is shared among other projects.
Why?
This rule enforces simplicity: there is no need to introduce too much
extern'al visibility of data structures and functions.
This rule enforces readability (even with very basic editors):
whenever you end up reading code at some function call, I hate it if I
then have to skip and seek for the right file containing the _actual_
implementation of that function. This basic rule makes it easier to
just skip around in a single file.
This rule enforces consistency: you avoid splitting up the code of a
program into arbitrary files that will always raise questions by other
readers/contributors (why did you put it here/there).
This rule lives well with source control: git can easily follow the
whole history of each line, no certain points in history where a file
was abandoned because of such proposals like yours. Each time when
browsing a git history such an event happened, means to the reader, he
has to make up his mind why this happened...
This rule keeps SLOC down: probably the most important aspect: the
size of a program.c file forces its authors to keep the SLOC down,
because it is a good mirror if one can still understand the code
altogether. Having dozens of .c files let's you easily end up in a
different situation after some years.

Best regards,
-Anselm
Received on Mon May 16 2016 - 07:24:24 CEST