[sane-devel] [janitorial] leading whitespace: spaces XOR tabs

Johannes Meixner jsmeix at suse.de
Thu Jul 13 09:03:49 UTC 2017


Hello,

only side-notes FYI (and somewhat off-topic):


On Jul 12 10:23 m. allan noah wrote (excerpt):

> 1. I routinely use git blame to find out when I changed some line of
> code. A massive whitespace commit would wreck that. Yes, there are
> other ways to get that info after such a cleanup, but I'm lazy :)

Because there are also various other reasons why 'git blame'
does not show who made substantial code changes, I personally
use meanwhile only

git log -p --follow <filename> | less

to find out who relly changed what in a substantial way
and even more at the same time I can easily see how
a part of code changed over the time (e.g. to find out
possibly "false fixes" in the past).


> 2. I've read a great deal of other people's code over the years,
> and I am generally stumped by their logic and lack of comments.
> Whitespace is rarely a concern, even when they used a weird layout.

I cannot agree more with "stumped by ... lack of comments", cf.
https://github.com/rear/rear/wiki/Coding-Style

In my opinion
first and foremost source code is there to tell others (humans)
what the author had meant that the machine should do.
It is of secondary importance that source code tells the machine
what to do.

Strictly speaking
source code never tells the machine what to do.
Only machine code tells the machine what to do.
Humans make source code.
Tools make machine code from source code.
Source code tells tools what machine code to make.
I used simply "source code tells the machine what to do".

Reasoning:
If source code tells humans what is meant that the machine should do
but that source code tells the machine to do something different
(i.e. there is a bug in that source code), then other humans
can see the bug (i.e. understand the issue) and fix it.
In contrast when source code only tells the machine what to do
nobody can properly fix that source code in case of issues
(at least not with reasonable effort).
When there are issues with such source code, the proper way out is
to replace that useless source code with useful source code that
first and foremost tells humans what is meant that it should do.

Simply put:
Source code that is for machines but not for humans will die out.
Or in other words:
Humans will delete source code that is for machines but not for humans.

See also Eric Raymond's "Rule of Clarity" at
https://en.wikipedia.org/wiki/Unix_philosophy
or directly at
http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877610


> 3. There are patches floating around in private repos that may not
> apply cleanly after such a change.

On the other had when only using spaces (but no tabs) all
indentations look well even in 'diff' output (i.e. in patches)
which aids readability of patches for humans.



Finally I think Olaf Meeuwissen should do us all a favour and
let make us all more money by using spaces instead of tabs ;-)


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)




More information about the sane-devel mailing list