Ask HN: What code do you frequently read?
Be it for beauty,or for reference, elegance, whatever... what is a piece of code that you find yourself returning to frequently
Looking through my code reminds that I can do hard things. I can solve hard problems, even elegantly. Other times it reminds me how painful a project was to finish or I chuckle at how BAD of a coder I was back then compared to now. It helps me feel like I'm making progress despite the relentless stack of issues, problems, and assignments.
And when I do feel motivated to be a better coder, I try to explain somebody else's source code to somebody else. It helps me be a better reader and writer.
I think some of the best code I use is that which I don't look at frequently, because it means it's behaving well on its own / in concert with other components, and is abstracted enough that it doesn't require changes.
* Do the tour (tour.golang.org)
* Read 'How to Write Go Code'
* Try to write a simple, concurrent program (I went with a web crawler)
* Read 'Effective Go', stdlib code
And now I'm trying to make the concurrent web crawler distributed! It's a lot of fun so far.
https://github.com/golang/go/blob/master/src/strings/reader....
Some questions that come to me when looking at that code:
- In general, why is everything abbreviated? Storage isn't an issue and IDEs solve the typing problem. It feels really old school. Plus you lose a lot of meaning throughout the code (r.prevRune is actually an index, so why not reader.previousRuneIndex, or at least r.prevRuneIdx)
- What is int64? A cast? Why would you need to cast what appears to already be an int?
- what is a Rune? Why are we setting it to -1? -1 just seems like a special number that would make this more readable as a constant with a relevant name.
- Where does copy come from? why does it appear to work backwards compared to any other language array copy implementation?
- Why does the last return statement return nothing?
I'm not here to start a language war, I truly believe it is my inability to see the forest for the trees, but I find Go code to be hard to read and understand.
2. Yes, int64() is a cast to an int64 type. The bare "int" type in Go is architecture-dependent, so the compiler will complain if you try to assign an int to an int64 without the cast.
3. Rune is a number representing a UTF-8 codepoint. It's an alias for int32 the way "byte" would be an alias for in8. (http://golang.org/doc/go1#rune)
4. copy() is a built-in function. There's only a small handful of built-in functions defined, and they're all documented here: http://golang.org/pkg/builtin/
5. The last return statement doesn't specify any values because the method signature has already assigned names to those: n for the int, and err for the error, so an empty return means "return the values of the variables n and err", which default to their respective type's 0 values (0 and nil for int and error). Returning the values explicitly still works as seen in that example, and is slightly shorter than "n = 0; err = io.EOF; return".
Go can be tricky to read if you're not familiar with some of the semantics, but once you've ramped up a little bit, then things just start falling into place.
If I can't read the code because it's proprietary, I always strace it to see what it's doing.
For me, it makes it easier to reason about the behavior of my program.
Currently my favorite code to read includes: key/value databases written in C and other "lower level" languages, and the golang standard library packages.
When you launch htop, you will see a list of all your running procs. If you select a proc with the arrow keys, you can hit "s" to start a strace and then hit f4 to follow the strace as it dishes output.
This won't work for all procs, you will need root to strace certain procs.
This is a good place to start as it's visual and easy to follow. Later you can start traces from the shell with proc IDs and even get system call info from GDB.
https://www.google.co.in/search?q=code+reading+the+open+sour...
I read Django code when things go wrong or to implement e.g. an auth backend, or see how come get_by_native_key() doesn't always need to take a native key as a parameter.
So, about once every 6 months I read through it to see if there are any obvious features I can add. Then I read through it to see if there are features I can collapse. It's been interesting to see the features grow linearly, but the code base grow logarithmicaly.
People have asked me why I didn't just use LINQ to SQL or Entity Framework or whatever, but I don't think they understand that A) those things didn't exist at the time, and B) there's something about having a tool that you know inside-out.
In terms what I return to, I refer to the LZ algorithm quite often. LZ77 and LZ78 are beautiful in the simplicity and power of their logic. I used to like to look at PRNGs, for example the one in RC4, and hashes. I like the question -- "How do they get so much entropy from so few lines?"
Occasionally I'll look at a one or two line functional programming routine in Python to see about the question, "How can this be done more neatly, elegantly, simply or quickly?"
Algorithms are beautiful, not the code. Code is just worldly forms, which are all an illusion.
I haven't gotten to it yet, but hope to!
I frequently search Google for a class name and append 'site: github.com' in order to search all the source hosted on GitHub for examples on how others are using said class.
Reading the Quake stuff is doubly enjoyable thanks to Fabien Sanglard's excellent Code Review series: http://fabiensanglard.net/quake3/ (he's also done them for many (all?) of the other open sourced id games.
I've found that diving into a code base is a great way to learn about a new topic or language, and to get rid of the "magic".
The closest is for a software library which I use only occasionally, where it takes a few non-intuitive lines to get things set up correctly. Someone developed an easier API for it, which is closer to the way I think about the problem. When I need to X, I consult that software to see how to implement it.
Unfortunately, he's up to day 75 and i'm still on day 11.
Also, Magento 2's code is beautiful, despite it's written in PHP :)
I really love the clean code the decompiler gives you, compared to packed JavaScript which is just a pain to read for a human.