We try to keep up, but the truth is that it's a 15 years old C++ codebase implementing some weird hardware in even weirder ways. We're far from where we'd want to be code quality wise -- close to no automating testing infrastructure, code is full of module-level globals, inconsistent conventions, etc.
- Balanced scorecard
- Bugs per line of code
- Code coverage
- Cohesion
- Comment density[1]
- Connascent software components
- Constructive Cost Model
- Coupling
- Cyclomatic complexity (McCabe's complexity)
- DSQI (design structure quality index)
- Function Points and Automated Function Points, an Object Management Group standard[2]
- Halstead Complexity
- Instruction path length
- Maintainability index
- Number of classes and interfaces[citation needed]
- Number of lines of code
- Number of lines of customer requirements[citation needed]
- Program execution time
- Program load time
- Program size (binary)
- Weighted Micro Function Points
- CISQ automated quality characteristics measures
'''
There are too many in very different domains and languages.
However, I opt for jQuery here. It is one of the greatest examples of how constant refactoring and thoughful usage of design pattern get you a very long way.
If you are designing JavaScript libraries, pls have a look at jQuery. So many great design decisions aka great code quality.
Pushing all dom manipulation through global evals seems like the exact opposite of thoughtful design to me. I have a long list of places where I want to implement strict CSPs, but can’t purely for minor use of jQuery.
As a C beginner getting into writing larger projects, especially in that sort of context, the quake source has been my reference on how to structure my code.
for sure not. OpenBSD makes no attempt to use proper performance which is critical for a kernel. there are so many naive ad-hoc data structures and algos, it's a shame to walkthrough.
How is performance related to code quality. That makes no sense. If anything, if you had to inline ASM for example, the code would suffer from readability.
I don’t see how those examples are relevant. Why would that last one be faster?
I agree that the OpenBSD code here is good, no more and no less than needed.
I assumed the grandparent was referring to cases where an O(n) algorithm is used where it might be O(log n) or O(1) with just a little more effort. It’s a tradeoff, sure, and in some cases linear searches can work surprisingly well, but in general I think this kind of thing should always be considered in good code.
Micro-optimizations like inline assembly for inner loops may or may not be a good idea, depending on the application. All else being equal, I’d certainly agree that good clean code would not use assembly.
I would expect the openbsd true to be the fastest, it doesn't need to spawn a subshell and it doesn't do more than the posix specification requires (afaik --help/--version should be ignored).
using comma seperated string splitting options over normal bits or'ed together in their public API looses all credibility in their engineering abilities. it would not survive any professional code review.
Once had to make some changes to OpenSSH for an internal project and it was surprisingly easy to find the relevant code and make the necessary changes. One of the few times my code worked on the first compile.
There's a lot to admire in OpenBSD but sometimes the peripheral tools they deliver don't work well. The example I know best is OpenNTPD (last link in your comment). It has a bunch of problems, including relatively poor clock discipline compared to other NTP implementations. And it doesn't even try to handle leap seconds. That causes problems on the machine itself which may or may not matter to you, but it's catastrophic if that OpenNTPD serves time to other servers. Unfortunately there's a bunch of OpenNTPD servers in the NTP Pool actively providing bad time. Some details from the 2016 leap second: https://community.ntppool.org/t/leap-second-2017-status/59/1...
Again I mostly admire OpenBSD. But OpenNTPD is not the best example of their work.
Yeah the stock old ntpd had a lot of unused code and various security problems over the years. It makes sense OpenBSD would replace it. Just a shame they didn't do it completely. I think that describes a lot of OpenBSD tools; you're trading off some functionality for very good security.
There are better NTP implementations now. Chrony is great, it's the default in Ubuntu now. NTPsec is coming along although I haven't tried to use it myself. Also good ol' ntpd is greatly improved.
Have you had a chance to look at systemd-timesyncd? I'm curious how it stacks up as a NTP client. Was thinking about switching my systems to it (from chrony) as I don't need the NTP server functionality.
Though core has some bad API due to maintaining backwards compatibility a lot of the third party libraries like requests, Flask have great focus on API design and code quality.
Agreed. Almost every time I've looked deeply into stdlib code I was surprised by how hard to follow it is and how frequently antipatterns are employed. Doubly so for anything near a C module.
I consider the Python stdlib in a similar vein as the C++ stdlib or Boost: Yes, some useful bits in there, but (1) lots of rot (2) you don't want to have your code look anything like it.
Agreed with the rest, I've ended up reading pypy's implementation of some functions sometimes to see how it works after trying CPython first. From the few I've read I'd say pypy looks nice by the way (I'm talking about standard library).
Although still in beta, I'd like to add BearSSL to the mix of well written and documented C libraries. In particular compared to the OpenSSL "documentation". It's also nice to see an TLS implementation without any memory allocations at all.
Strictly talking about code quality, I will nominate RCP100, which is a small, virtually unknown, now-abandoned routing software written in C [0]. I started programming with C way back in the 90s, and this is one of only two projects I can recall being immediately struck by the beauty of the code (Redis being the other). I know almost nothing about the author but he seems not to want to be known by name. You can browse the source on Github [1], which I uploaded myself, since you can only get a tarball from sourceforge. Anyway, as someone else mentions, C is usually a mess, but RCP100 struck me as beautiful.
Thanks for uploading RCP100. Your comment is a timely one. I wanted to learn how a router works and is built and was looking for a simpler implementation.
Can you recommend any resources from which I could learn more about network programming, so that I could understand RCP100 code better?
Why? I was able to do substantial changes to the kernel when I was a teenager (late 90s), mostly on my first try. There was no giant wall of abstraction I had to climb over or some huge swath of mutually interacting code I had to comprehend. There was also nothing that required fancy code navigation and the creation of something like the ctags database in order to find out what on earth was happening.
No action at a distance or lasagna style dereferencing or mysterious type names that are just typedef'd and #define'd around dozens of times back to something basic like char. No fancy obscure GNU preprocessor extensions or exotic programming patterns.
Nothing had obtuse documentation that tried my patience or required much more than enthusiasm and basic C knowledge.
I did things like got a wireless card working from code written for one with a similar chipset and got various other things like the IrDA transmitter on my laptop at the time to do a slattach and thus work as a primitive wireless network - all in the late 90s.
I likely had no idea what, say, the difference between network byte order and host byte order was at the time or how the 802.11b protocol worked or what a radiotap header was or any of that. The separation of concerns was so good however, that none of that knowledge was actually needed.
Compare that to say, the Qualcomm compatible WWAN I just dealt with over the past few weeks where I needed to have in-depth knowledge of an exhaustive number of things (very specific chipset and network details) to get a basic ipv4 address working. Then I needed to read up on GNSS technology and NMEA data to debug codes over USBmon to get the GPS from the wwan working. Then after I had the qmi kernel modules doing what I wanted and the qmi userland toolsets, I had to write some python scripts to talk to dbus to get the data from the modemmanager that I needed in order to log the GPS. All the maintainers of these pieces were very nice and helpful and I have nothing negative to say. This is just how it usually is these days.
Back then however, I wasn't a good programmer, I was likely pretty terrible in fact but with the NetBSD codebase I was able to knockout whatever I wanted every time, fast, on a 486.
What's your relation with it nowadays? I'm very curious about NetBSD but never tried it yet. I sincerely wonder what's your opinion on it now, and why you speak about the situation only as "those days" now? :)
I have no idea, haven't kept up with it. I'd recommend 1.x (<=4) any day though, simply for the education alone.
I don't really use it these days because I need systems that future cheap devs can maintain and once you enter userland it takes commitment and time I simply don't have to stay with netbsd.
Debian permits me to usually not have to care and that's pretty invaluable
> No action at a distance or lasagna style dereferencing or mysterious type names that are just typedef'd and #define'd around dozens of times back to something basic like char. No fancy obscure GNU preprocessor extensions or exotic programming patterns.
Ah, I see you've also looked at the Linux kernel code.
293 comments
[ 5.4 ms ] story [ 214 ms ] threadhttps://dolphin-emu.org/
e.g. The most recent https://dolphin-emu.org/blog/2018/09/01/dolphin-progress-rep...
That seems like it'd be terrible to try to get running reliably.
Software metric: https://en.wikipedia.org/wiki/Software_metric
''' Common software measurements include:
- Balanced scorecard - Bugs per line of code - Code coverage - Cohesion - Comment density[1] - Connascent software components - Constructive Cost Model - Coupling - Cyclomatic complexity (McCabe's complexity) - DSQI (design structure quality index) - Function Points and Automated Function Points, an Object Management Group standard[2] - Halstead Complexity - Instruction path length - Maintainability index - Number of classes and interfaces[citation needed] - Number of lines of code - Number of lines of customer requirements[citation needed] - Program execution time - Program load time - Program size (binary) - Weighted Micro Function Points - CISQ automated quality characteristics measures '''
Category:Software metrics https://en.wikipedia.org/wiki/Category:Software_metrics
However, I opt for jQuery here. It is one of the greatest examples of how constant refactoring and thoughful usage of design pattern get you a very long way.
If you are designing JavaScript libraries, pls have a look at jQuery. So many great design decisions aka great code quality.
Here's bitcoind: https://www.cvedetails.com/product/22744/Bitcoin-Bitcoind.ht...
* https://cvsweb.openbsd.org/src/
* https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/
* https://www.libressl.org/
* https://cvsweb.openbsd.org/src/usr.sbin/ntpd/
https://www.openbsd.org/faq/pf/perf.html
https://www.openbsd.org/crypto.html
https://www.openbsd.org/security.html
A C true would be: https://cvsweb.openbsd.org/src/usr.bin/true/true.c?rev=1.1&c...
Here's a much faster true(1) if you need it: https://github.com/coreutils/coreutils/blob/master/src/true....
I don’t see how those examples are relevant. Why would that last one be faster?
I agree that the OpenBSD code here is good, no more and no less than needed.
I assumed the grandparent was referring to cases where an O(n) algorithm is used where it might be O(log n) or O(1) with just a little more effort. It’s a tradeoff, sure, and in some cases linear searches can work surprisingly well, but in general I think this kind of thing should always be considered in good code.
Micro-optimizations like inline assembly for inner loops may or may not be a good idea, depending on the application. All else being equal, I’d certainly agree that good clean code would not use assembly.
I would expect the openbsd true to be the fastest, it doesn't need to spawn a subshell and it doesn't do more than the posix specification requires (afaik --help/--version should be ignored).
Once had to make some changes to OpenSSH for an internal project and it was surprisingly easy to find the relevant code and make the necessary changes. One of the few times my code worked on the first compile.
Again I mostly admire OpenBSD. But OpenNTPD is not the best example of their work.
Maybe I'll check that at home (where I replaced FreeBSD's ntpd with OpenNTPd).
There are better NTP implementations now. Chrony is great, it's the default in Ubuntu now. NTPsec is coming along although I haven't tried to use it myself. Also good ol' ntpd is greatly improved.
https://chrony.tuxfamily.org/ https://www.ntpsec.org/
https://www.openbsd.org/goals.html
[Can't speak for the 'highest' part of the qn, but Gensim upholds very high code quality standards]
The authors have good quality repos :
https://github.com/kennethreitz
https://github.com/mitsuhiko
I consider the Python stdlib in a similar vein as the C++ stdlib or Boost: Yes, some useful bits in there, but (1) lots of rot (2) you don't want to have your code look anything like it.
Often codebases written in C are a a mess to understand, a mess to read. The Redis Source Code is understandable even without deep knowledge of C
Came here to say exactly this - Redis is very cleanly written.
Hands down Symfony.
https://github.com/google/leveldb/blob/master/table/table_bu...
https://github.com/google/re2/blob/master/re2/nfa.cc
https://github.com/withspectrum/spectrum Https://spectrum.chat
I have heard good things about sqlite, and some day, I plan to read it :-)
[0] http://rcp100.sourceforge.net/
[1] https://github.com/curtiszimmerman/rcp100
Thanks for uploading RCP100. Your comment is a timely one. I wanted to learn how a router works and is built and was looking for a simpler implementation.
Can you recommend any resources from which I could learn more about network programming, so that I could understand RCP100 code better?
Thanks!
Why? I was able to do substantial changes to the kernel when I was a teenager (late 90s), mostly on my first try. There was no giant wall of abstraction I had to climb over or some huge swath of mutually interacting code I had to comprehend. There was also nothing that required fancy code navigation and the creation of something like the ctags database in order to find out what on earth was happening.
No action at a distance or lasagna style dereferencing or mysterious type names that are just typedef'd and #define'd around dozens of times back to something basic like char. No fancy obscure GNU preprocessor extensions or exotic programming patterns.
Nothing had obtuse documentation that tried my patience or required much more than enthusiasm and basic C knowledge.
I did things like got a wireless card working from code written for one with a similar chipset and got various other things like the IrDA transmitter on my laptop at the time to do a slattach and thus work as a primitive wireless network - all in the late 90s.
I likely had no idea what, say, the difference between network byte order and host byte order was at the time or how the 802.11b protocol worked or what a radiotap header was or any of that. The separation of concerns was so good however, that none of that knowledge was actually needed.
Compare that to say, the Qualcomm compatible WWAN I just dealt with over the past few weeks where I needed to have in-depth knowledge of an exhaustive number of things (very specific chipset and network details) to get a basic ipv4 address working. Then I needed to read up on GNSS technology and NMEA data to debug codes over USBmon to get the GPS from the wwan working. Then after I had the qmi kernel modules doing what I wanted and the qmi userland toolsets, I had to write some python scripts to talk to dbus to get the data from the modemmanager that I needed in order to log the GPS. All the maintainers of these pieces were very nice and helpful and I have nothing negative to say. This is just how it usually is these days.
Back then however, I wasn't a good programmer, I was likely pretty terrible in fact but with the NetBSD codebase I was able to knockout whatever I wanted every time, fast, on a 486.
I miss those days.
I don't really use it these days because I need systems that future cheap devs can maintain and once you enter userland it takes commitment and time I simply don't have to stay with netbsd.
Debian permits me to usually not have to care and that's pretty invaluable
Ah, I see you've also looked at the Linux kernel code.