8 ms·
SQLite. and for this reason alone! https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html As of version 3.23.0 (2018-04-02), the SQLite
by tzury 8y ago
SQLite.
and for this reason alone!
https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html
As of version 3.23.0 (2018-04-02), the SQLite library consists of approximately
128.9 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in
other words, lines of code excluding blank lines and comments.)
By comparison, the project has 711 times as much test code and test scripts -
91772.0 KSLOC.
- IshKebab 8y agoThat doesn't mean their code is necessarily nice.
- Daviey 8y agoInversely, this is counteracted by the logic to not use Git: https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html
- raverbashing 8y agoBut to be honest, this is mostly fair criticism. Not sure why they need some of those things, but if they need it, then it's fine.
- deanishe 8y agoIt's explained in more depth here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik... Essentially, git is designed for the "bazaar" development model, while Fossil is designed for the "cathedral" one, which is what SQLite uses, being developed by just three guys working very closely together.
- Drdrdrq 8y agoThos is not the reason. The real reasons are explained quite nicely here [0] and I agree with all of them - though I still use Git because of network effects. My alternative of choice would be hg. [0] https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html
- vnorilo 8y agohow would using a specific vcs improve the code quality?
- Daviey 8y agoThis was a response to test coverage used as a benchmark. I see them both as an indirect project quality benchmark. Neither is directly representing the actual code quality but does indicate if it is a project that matches my view of a mature project. Sure, others will disagree - but the whole idea of quality in this context is subjective anyway.
- utahcon 8y agoThe most interesting thing (IMO) left out of this page is the fact that D. Richard Hipp is the author of Fossil. This has a particular smell factor to it, not sure if it is a good or bad smell.
- TeMPOraL 8y agoTangent: I always thought SLOC means "significant lines of code". Since "code" is a shortand for "source code", expanding SLOC as "source lines of [source] code" makes little sense, IMO.
- elviejo 8y ago"Source lines" includes lines with comments, empty lines and code. Source lines of code... Specifies only lines with code, no comments
- dx87 8y agoI always thought it meant "single lines of code", like if line breaks added for formatting had been removed so every statement had its own line.
- nathell 8y agoAnd this: https://www.sqlite.org/malloc.html https://www.sqlite.org/malloc.html "SQLite can be configured so that, subject to certain usage constraints detailed below, it is guaranteed to never fail a memory allocation or fragment the heap."
- gardaani 8y agoAnd all that is public domain: https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html
- anewhnaccount2 8y agoNot all of the test suite is public domain. That's how the authors maintain a monopoly on improvements to the code.
- anewhnaccount2 8y agoAs a point of information, I wasn't using monopoly in a particularly pejorative sense, but more just to explain the situation. Feel free to replace with a less loaded word in your head.
- ttty 8y agoSo you measure good code by the number of test lines?
- gameswithgo 8y agoA better comparison would be some sort of defect rate. Does SQLLite manage less defects per line of code per month (or whatever) than PostgreSQL with that test suite? Is there a distinction between the best codebase and the best test suite? Probably.
- danmaz74 8y agoAutomated testing is useful and good. But I really feel it's reached a lever of fetishisation that is quite concerning. Testing code is code which needs to be written, read, maintained, refactored. Very often nowadays I have to wade through tests which test nothing useful, except syntax. Even worse, with developers who adopt the mock-everything approach, I often find tests which only verify that the implementation is exactly the one they wrote, which is even worse: it makes refactoring a pain, because, even if you rewrote a method in a better way which produces exactly the results you wanted, the test will fail. So, the ratio of testing code vs implementation code is a completely wrong proxy for code quality. EDIT: I'm not criticising SQLite and their code quality - which I never studie - but the idea that you can judge code quality for a project just by the ratio of test code vs implementation code.
- lolc 8y agoWhile I agree in general I disagree here. If you read about the Sqlite tests you will find that they do test sensibly. One suite I'm particularly impressed with will run tests from zero bytes with slowly increasing available memory until the program passes. The tests verify that at no point the DB is corrupted by an OOM event.
- danmaz74 8y agoJust to clarify, I wasn't criticising sqlite, I was criticising the idea of judging their code quality "for this reason alone!" - ie that they have so much test code vs implementation.
- lolc 8y agoSure! Can't judge a book by its size. As a heuristic the code versus test-code ratio serves well as an indicator of quality. Just like consistent indentation does. You don't know whether a well-indented program is good. But if the indentation is inconsistent you'll expect worse.
- faitswulff 8y agoThey actually have to test to that degree to follow aviation standards (DO-178b [0]) because they're used in aviation equipment. Dr. Hipp said he started really following it when Android came out and included SQLite and suddenly there were 200M mobile SQLite users finding edge cases: https://youtu.be/Jib2AmRb_rk?t=3413 https://youtu.be/Jib2AmRb_rk?t=3413 Lightly edited transcript here: > It made a huge difference. That that was when Android was just kicking off. In fact Android might not have been publicly announced, but we had been called in to help with getting Android going with SQLite. [Actually], they had been publicly announced and there were a bunch of Android phones out and we were getting flooded with problems coming in from Android. > I mean it worked great in the lab it worked great in all the testing and then [...] you give it to 200 million people and let them start clicking on their phone all day and suddenly bugs come up. And this is a big problem for us. > So I started doing following this DO-178b process and it took a good solid year to get us there. Good solid year of 12 hour days, six days a week, I mean we really really pushed but we got it there. And you know, once we got SQLite to the point where it was at that DO-178b level, standard, we still get bugs but you know they're very manageable. They're infrequent and they don't affect nearly as many people. > So it's been a huge huge thing. If you're writing an application deal ones, you know a website, a DO-178b/a is way overkill, okay? It's just because it's very expensive and very time-consuming, but if you're running an infrastructure thing like SQL, it's the only way to do it. [0]: https://youtu.be/Jib2AmRb_rk?t=677 https://youtu.be/Jib2AmRb_rk?t=677 "SQLite: The Database at the Edge of the Network with Dr. Richard Hipp"