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 <gerh...@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@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 -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand" -- 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