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

m. allan noah kitno455 at gmail.com
Wed Jul 12 14:23:23 UTC 2017


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 :)

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.

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

Given those, I'm inclined to leave maintained backends untouched. For
unmaintained backends, it certainly makes sense to do such
reformatting when a bugfix is done. Doing it beforehand is
questionable, I don't feel strongly either way. I suppose cleaning up
the unmaintained backends makes it slightly easier for a new
maintainer to step into the code.

allan

On Wed, Jul 12, 2017 at 9:35 AM, Gerhard Jäger <gerhard at gjaeger.de> wrote:
> Hi Olaf,
>
> On 12.07.2017 at 14:33 Olaf Meeuwissen wrote:
>>
>> Hi all,
>>
>> I just committed the last compiler warning fixes and made the Debian 9
>> builds "AWARE".  Now any compiler warnings on all 4 Debian builds will
>> bomb the build in question and hence prevent the creation of a new
>> snapshot tarball.
>>
>> I mentioned[1] that the plustek-pp backend's indenting defied me but
>> after some staring at the code I realized it was using a four spaces to
>> the tab convention.  Convincing my editor to do the same made it a lot
>> easier to understand the intended behaviour but fixing the "mess" was
>> still a very delicate affair.  I had to change the mixed use of spaces
>> and tabs used to indent to *exactly* match in order to silence compiler
>> warnings.
>>
>>   [1]
>> https://lists.alioth.debian.org/pipermail/sane-devel/2017-June/035445.html
>
>
> [...]
>
> I obviously ignored you - sorry for that. And yes, I did follow at these old
> days my own rules, not using tabs, but 4 spaces - in an inconsistent way.
> Sorry - 'twas a long time ago ;)
>
>> This whole exercise has made me look at the whole code base in a little
>> more detail and, quite frankly, the use of leading whitespace is a total
>> and utter mess.  Some places are better of than others but on the whole
>> it's pretty pathetic.
>>
>> # Just make your editor visually distinguish spaces and tabs and you'll
>> # see.  I used Emacs' whitespace-mode (in its default configuration) and
>> # it "lit up the place" in a variety of colours.
>>
>> So here's a few "rules" I'd like to apply in order to address this.
>> Each file
>
> [...]
>>
>> # Personally, I would much prefer to uses spaces everywhere the file
>> # format permits (with a minor execption for files used by make, see
>> # above) over the board.
>> # You may find the following blog post of interest ;-)
>> #
>> #
>> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
>>
>> If anyone objects, I'm open to suggestions, including "Why bother? Just
>> use spaces!" ;-)
>>
>> If I hear nothing, the tools/style-check.sh script will be modified to
>> implement these rules and can then be use to check for any "violations"
>> and (recursively) fix them.
>
>
> Are you sure you want to rework the whole code base? Is it a good idea?
> Well maybe for unmaintained backends, but what about the others? In fact
> I have here some long pending patch (64 bit awareness) that most probably
> no longer apply.
>
> Just my two cents,
>  Gerhard
>
> BTE: Thanks for caring anyhow.
>
>
> --
> sane-devel mailing list: sane-devel at 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-request at lists.alioth.debian.org



-- 
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"



More information about the sane-devel mailing list