[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.
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 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
> 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 ;-)
>> 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,
> BTE: Thanks for caring anyhow.
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> 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