Hacker News Reader

Comment by danbruc | Hacker News Reader

This does not resonate with me at all. I can not stand having things in my code I don't fully understand. Without reading the source code of libraries, without reading relevant standards, without understanding the mathematics behind algorithms, there is always this feeling I may make really dumb mistakes. Really understanding all the bits and pieces obviously does not make your code bug free, but I am usually pretty confident that I did not do something horribly wrong.

View on HN

This piques my interest. When was the last time anyone read the source code of (g)libc "cover to cover" before using it? Does anyone know the precise implications of (not) defining any of the myriad sensible permutations of its "feature test macros"? Is anyone even sure that those implications are actually implemented correctly before relying on them?

I obviously do not and can not trace the entire code path from a print statement through the class library, the operating system, the display driver and the hardware, some things I will still take for granted. But if there is a really critical aspect to what I am doing, say some thread synchronization, I will definitely not just follow some sample code, but read the relevant parts of the memory model of the language specification detailing why this works as expected. If the underlying hardware matters, I will grab the reference manual for it, too.

A lot of this is surly curiosity and you can get away without it most of the time, but at least as soon as I run into the first problem it really helps me a lot to have at least a basic understanding of what is going on in the layer of abstraction I am interacting with and maybe a layer or two below. And it gives me a really comforting feeling, that I know what is going on better than describing it as some black magic.

The computer doesn't care which code you consider to be in the scope of your concern, and which you take for granted.

If you examine why you're concerned about some code more, you will probably come to the realization that you're less confident in it because it is less old and mature, has fewer users, and has had fewer developer eyes on it and such.

I.e. whether explicitly or not, you're focusing your understanding where it will be needed and that coincides with where there is more risk if you don't understand.

It's not about the quality or maturity of the code I am relying on, it's about the quality of my code. I want my code to do the right thing in the simplest and most elegant way possible and part of this is knowing really well how everything works.

There's no reason to read it "cover to cover", and the GP did not really ask for that. There are many functions in glibc which can be read and understood in relative isolation. I find myself reviewing stable library code (glibc, ncurses, zlib C++ STL) in fits and spurts, several times a year. Sometimes that is paranoia (download the source to make sure the code matches the behavior described in man pages), but mostly it is spelunking to verify something impementation-specific.

But what does it mean to fully understand your own code? Everyone relies on millions of lines of code that they didn't write themselves.

For me that really depends on what I am dealing with. Most of the time the library source code is good enough. Sometimes - I am a C# developer - I will have to have a look at the .NET runtime specification. Sometimes I will have to learn details of Windows. In some cases I will even look into Intel's reference manuals to understand what is happening. I would say I stop at the level where I don't expect the layer below to be relevant to what I am actually dealing with.

Reply on news.ycombinator.com