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) -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org