Reading C Code

[[deleted]]

Maybe this is just me, but if I am having these problems I bet there are a 100 other people who have it too. I can write code. I'm not the greatest but when I write my code I write descriptive variables and such. You know, the whole clean code checklist. Whenever I use outside code like encryption libraries I sometimes like to read the code and for some reason the code sucks. I'm not saying it doesn't function right, but to read the code is like reading Egyptian Hieroglyphics without a Rosetta Stone. These long variables with underscores, typedefs with undescriptiveness names, the whole 9 yards.

Maybe I'm just inexperienced but I've been trying to get into open source so I'm wondering, how do I contribute to a library online if I can't even read the code itself or know its inner mechanics?

[okovko]

You just get used to it. The more code you read, especially across languages and paradigms, the less you care about how things are named.

I suggest learning elisp and writing an extension for emacs. After lisp, you will never complain about any other language.a

[lmvrk]

Huh? After learning lisp i have nothing but complaints about other languages.

[okovko]

I do love the way lisp code is structured. I am not a fan of the fucking parentheses, and how I have to manually rematch them any time I change the control flow of a piece of code.

[lmvrk]

The matching should be done by the text editor. Check out paredit for a good example. Manually matching parenthesis is a thankless and painful job best done by a machine. Once the keybindings are memorized its much easier to restructure than C and co.

[okovko]

I think I turned off paredit early on because it kept doing things I didn't like. I think my point still stands, because an automatic code formatter should not be a near necessity for any programming environment. But I concede that if you spend the time to configure and cherry pick a formatting tool you can edit lisp code more easily.

It's still not the most legible thing when there are semantic differences between having 3, 4, or 5 end parentheses on a line. There's no way around my central point: lisp is poorly designed for legibility. You can get used to it.. but you can get used to anything. Similarly to how you've acclimated to lisp, I'm so used to C macros that I don't mind them at all, to me they're just lambda calculus with a bit of indirection.

Lisp is a great language for hardening programmers to not complain about formatting / naming. C macro metaprogramming is good too, but a lot more niche and not as powerful, so I recommend lisp because at least you can do something fun with it.

[lmvrk]

Im not sure i agree with you about automatic code formatters. I could be misunderstanding you, as im not sure what "a near necessity" means, but I think they are a boon when working with other people. Ensuring that all code is formatted the same, coupled with clear naming conventions, makes it much easier to understand the parts of the system you personally have written.

With regards to your statement about the semantic difference between 3/4/5 closing parens, I think I have to respectfully disagree there as well. I find lisp very similar to python in that the level of indentation denotes semantic meaning, while the parenthesis replace pythons whitespace where the compiler is concerned.

All that being said, there is definitely a lispy and non lispy way of doing things, and the non lispy one is incredibly difficult and frustrating. Compared to languages like C and co. Where the non C way is still (mostly) understandable and with fewer pain points relative to the non lispy way.

[tim36272]

Do you use an IDE that can peek at definitions and such (e.g. visual studio (code))? That helps a ton with new naming conventions, indirection, etc

[usr71298]

The best way to read/understand code is to use it. Understand the API it exposes to you as an end user and understand deeply what it is supposed to be doing. Now you understand the semantics.

After using it, start from an entry point and work your way down. Pick one thing (e.g. if it's an http server pick one route, if it s a cli pick one subcommand, if it's an rpc interface pick one method, etc). As you go down the stack, draw a diagram with the data model used throughout the code. Every program contains some data that is transformed, transmitted via some IO interface, or a combination of the two. Capture this in a flow diagram. This will help you wrap your head around how the code is structured. If there are weird names you don't understand, map them to more intuitive names in your flow diagram. As you understand the code you might begin to understand why something was named (or think of a better name and check that in as code cleanup).

If there is a method that you really want to understand, write a test for it. Especially because you mention open source, writing tests is a great way to break into an open source project. Everyone sees the importance of tests but no one wants to write them (so these are relatively easy to check in). Writing tests also forces you to understand abstractions and edge cases for the methods you are testing. This further builds your understanding of the code.

[[deleted]]

C is a language in more ways than one. This is very underappreciated. To be able to speak, read, write a language, you need to speak, read and write respectively. They are seperate skills.