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. ]