Formatting of SQLite files
(1) By aaronfranke on 2020-06-23 17:35:09 [source]
In downstream projects, I would like to enforce file formatting. I recently made this script which does things like ensure POSIX compliance, removes CR, removes BOM, and removes trailing space characters: https://github.com/godotengine/godot-demo-projects/blob/master/format.sh
In the case of SQLite, this script produces a ton of diffs, since SQlite is filled with useless trailing space characters. I was going to submit a pull request to the upstream repository, but I have no idea how to use Fossil, and even if I did, I have no idea how to submit patches (there is no button for such a thing on the timeline, or even a contact email).
I'm hoping that a SQLite developer sees this and will run the formatting script I linked above on the SQLite repository. I would greatly appreciate it, and it would reduce the size of the files since it removes useless characters, so it would benefit everyone.
Two notes: One, the script is currently designed to iterate over files tracked by Git. I think the easiest option is that you can just drop the files into a Git repository and copy-paste them back when you're done. Two, you will need to run the script multiple times since some lines have multiple trailing spaces.
(2) By Richard Hipp (drh) on 2020-06-23 17:59:28 in reply to 1 [link] [source]
Please try again using the latest Prerelease Snapshot of SQLite and report back if you are still getting warnings about end-of-line whitespace.
(3) By Keith Medcalf (kmedcalf) on 2020-06-23 19:02:35 in reply to 2 [link] [source]
Richard, this fixes the sqlite3.c and sqlite3.h output files, but does not fix the files in the canonical distribution, which are chock full of trailing whitespace.
(4) By Richard Hipp (drh) on 2020-06-23 19:05:24 in reply to 3 [link] [source]
That is correct. Changing the input files would create a lot of diffs that would complicate historical tracking. And since the change serves no actual purpose (other than to placate style-enforcement tools) it would do more harm than good.
(5.1) By TripeHound on 2020-06-23 19:41:15 edited from 5.0 in reply to 1 [link] [source]
In passing: the
sed I have immediate access to doesn't seem to support
\x20, so I can't test it, but if you change:
sed -z -i 's/\x20\x0A/\x0A/g' "$f"
sed -z -i 's/\x20\x20*\x0A/\x0A/' "$f"
or perhaps (which I have tested):
sed -z -i 's/ *$//' "$f"
I suspect you wouldn't need to make multiple passes for lines with more than one trailing space.
(6) By aaronfranke on 2020-06-24 03:49:54 in reply to 4 [link] [source]
I heavily disagree with this, well-formatted code is a great way to improve software quality, since it improves readability and reduces the chance of mistakes.
If you are worried about complicating history, what you would ideally do is have a CI check or a pre-commit hook (idk if that exists in Fossil) to automatically run formatting tools, so that useless trailing spaces never get into the repository in the first place.
In fact, it would also be nice if something like clang-format was enforced too, but it's not my place to tell you how to format your code, and clang-format isn't related to my immediate problem of diffs on SQLite files caused by format.sh.
(7) By Larry Brasfield (LarryBrasfield) on 2020-06-24 08:00:36 in reply to 6 [link] [source]
The trailing whitespace does not affect how the code is displayed in any common context where its readability is an issue, so your stated "disagree" rationale is unpersuasive and unavailing.
If you are planning to use the SQLite sources in the form they have within the repository, you can easily apply your fixup there and continue to incorporate updates. The trailing whitespace will not suddenly reappear except in rare cases, and you are free to reapply your fixup upon every update.
If you use the SQLite amalgamation, your "problem" [a] is already eliminated going forward, as of yesterday afternoon. The same person you attempt to instruct about software quality has altered the amalgamation construction process to remove its trailing whitespace, shortening about 3% of its lines. Future amalgamation releases will be similarly shortened.
[a. As a self-induced problem, it truly is yours. ]
In closing, I note that the cost/benefit analysis with which you heavily disagree, (obscuration of functional changes versus satisfaction of an outsider's arbitrary formatting standard), involves weighing effects likely to impact the SQLite dev team against effects with impact that is nigh impossible to discern. You would weigh them differently, but I suspect that is because you would bear little [b] of the cost and you seem to overvalue the benefit. I think it likely that the superfluous whitespace is there because, being invisible in most editing tools, it escapes notice. If it truly degrades readability as you suggest, perhaps you need to configure your editor differently, at least when reading other's code.
[b. I say "little" because there could be an impact upon the library as extra developer time is spent sorting out trivial, non-functional changes from the ones that affect function. ]