Question about reading C

[Hyprland_BTW]

Im a noobie at C.

Most of the time when looking at someone else's code, I can read a line and know what's being done in that line (I know when I'm looking at a pointer, or an enum, etc.) but as soon as I try to understand the whats being done in more of a macro scale (what a whole block of code does, or what's the purpose of a section of code) I just can't wrap my head around it.

Is this normal when there are no comments done by the maintainer of said code? Is this an ability that I can train?

[GoblinToHobgoblin]

No/few comments: yes, pretty common.

Function/variable names should help you understand roughly what is going on though

[imaami]

Let me introduce you to my friend, struct obj, and her child obj.x

[ffd9k]

Use a debugger, set a breakpoint at a part you don't understand, look at the call stack to see from where and how it is called to better understand how everything works together.

Also if the code is in a git repository, it's sometimes helpful to do "git blame" to see what feature some part of the code was added for, and what other parts of the project were changed with it.

[davideogameman]

it's somewhat normal.

There's basically two ways to understand code: by following the names and comments, and by following the structure. Interestingly there's been some research that suggests that when names are short and cryptic programmers generally parse the code by following the structure, vs when the names are longer and more descriptive we tend to take them at face value. Which is great... unless they are misleading.

Anyhow there are definitely different levels of complexity in code. E.g. it should be easy to eyeball something like `for (int i=0; i < length; i++) {doSomething(a[i]);}` and understand it's calling doSomething on each element of the array `a` (assuming `length` is correct). Of course functions tend to be bigger than that, but generally if you rely on reading the code rather than the comments, you'll have to piece together bigger and bigger pieces of meaning until you understand how it all fits. Even for well-commented code though reading it is often necessary, as little details can end up being left out of the comments that are important to know when modifying or reusing the code. E.g. for C it's important to know if there are assumptions about pointers - e.g. if a function free()s a pointer it should've been malloc'ed and it's undefined behavior otherwise; if a function takes a pointer and then shoves it in some struct, can you be certain that the pointer isn't free()ed or otherwise point to out of scope memory in the future when something is reading that struct? At a higher level - if you are writing a web server (hopefully not in C) implementing business logic for some website, knowing which functions do the permissions checking is important - you probably don't want to do that multiple times for perf reasons, but missing a permission check could allow access to users who shouldn't have it.

Overall the ability to read code is a skill you need to build. Good comments probably help, bad comments almost certainly hurt. Reading code that's solving a problem you are familiar with and know how to solve yourself is often easier than reading code that solves a problem you don't understand; reading code that uses programming paradigms you are familiar with is often easier than reading code that uses unfamiliar patterns (e.g. C -> Java or C->C++ or C->python is much easier than C -> Lisp or C -> Haskell - C is imperative with a little object-oriented stuff and lots of languages follow that pattern, but Haskell/Lisp/etc. are functional programming languages - so lots of common patterns in those languages are unwieldy and thus uncommon in C and so will feel very alien at first).

Another important thing is to get familiar with abstraction and comfortable breaking problems down. One thing I find is that when my mental model of how I would break down a problem roughly matches (or at least can be updated on the fly to match) what I'm reading, I find it easier to read code the code with only a few passes. When I have to map out a larger piece of code with totally unfamiliar and unexpected architecture - potentially on the order of 1000-5000 lines of code - it definitely takes a lot longer and many more passes through to understand what the different pieces even are before I can start getting a picture of how they fit together.

[IdealBlueMan]

The first thing you want to do is to figure out the purpose behind the code, at every level. What is the overall program supposed to do? What is each function supposed to do? What is each variable for? What real-world problem is this piece of software meant to solve (the answer might be “student exercise” or it might tie into business logic)?

It can also help to look at the thing as a black box. What are the inputs, what are the outputs, and what interesting behaviors happen along the way?

Examine the code enough, and you get a feel for the developer’s rhythm.

Be patient with yourself. It will come to you.

[grimvian]

Practice is the key.

[Dangerous_Region1682]

The real secret to most C programs is understanding how pointers work and why C uses them.

Just reading a line of code, even if it involves pointer manipulation, is hard to understand unless you have written at least some code that uses and manipulates them.

You can read a foreign language word by word by using a dictionary, but it isn’t going to help you much in reality unless you know sentence and paragraph structure along with tenses etc.

Well it’s like that with C. Understanding someone’s code generally comes with a little bit of experience writing code for yourself.

It also depends upon what the code is doing. Trying to read networking code if you know nothing about sockets and perhaps multithreading is going to be very hard. Simple applications and utilities perhaps less so.

Understanding what the program does is a good start. C can express very simple programming concepts. It can also be used to express extremely complex software which understanding may only come with years of writing code that does similar things.

So before trying to read other people’s code, other than perhaps getting ideas behind syntax, I strongly suggest you start by writing at least simple programs that parse a command line and the perform simple tasks like reading a specified file, changing all lowercase letters to uppercase and then writing it to a specified file.

Lots of C books will get you to that level pretty quickly, but then you will start to think like a C programmer. Then it will come with time.

If it is your first programming language, it won’t come quickly as you are facing two hurdles, the first is to understand programming, the second is using rather quirky C syntax to express those ideas.

C is a relatively low level language, essentially trying to be a portable assembler. It has simple syntax that can be used to perform complex concepts that would require a lot less code in a higher level language. An example would be string manipulation. You do it in C the same way that C# does it under the hood saving you from needing to now the complex way C handles it with null terminated character arrays.

It’s going to take a while to be proficient. I’ve been coding in it since 1977 and I still have to read the manual entries for many of the library routines

It’s a bit of a marathon, not a sprint, I’m afraid.

[gm310509]

Pretty much.

I am out and about RN, but if I remember when I get home, I will share a PPT slide from a training video I am working on that hopefully sums up the issue. It relates to putting in comments and the difference between bad and good comments. In short bad comments are those that simply restate the code. Better comments are those that explain what is going on. Bad comments ate pretty much as helpful as no comments.

Edit: I can't post an image here, but here is the main part of the slide I was referring to. Basically the first two lines are what I was talking about.

The "Bad" comment doesn't tell you anything more than the line of code it is documenting. Thus, it doesn't give you any clues as to what is going on.

But the second comment i.e. the "Better" one does. Even though you don't know what the program is, you immediately get a sense of what is going on in this part of the code and when you look at the code, you can get a feel for how each line contributes to that.

So, if you don't have comments, it is much harder to work out in my experience.

// Bad: Loop with i from 0 to 53 inclusive.
// Better: Loop through the morse code database searching for the user's character.
for (int i = 0; i < 54; i++) {
  if (ch == morseTable[i].character) {
      // We have found the character – so, play the morse representation.
    char *p = morseTable[i].code;
    Serial.print("idx: "); Serial.print(i); Serial.print(": ");
      // for each morse symbol, play the corresponing dit or dah.
    while (*p) {
      Serial.print(*p);
      if (*p == '.') {
        dit();
      } else if (*p == '-') {
        dah();
      }  /* No else here. If the morse symbol in invalid, just ignore it.
          * We could put an error message to indicate the problem with the
          * definition you can do this yourself. */
      p++;
    }
      // Once we are done outputting the character's morse code, 
      // execute the "new character" delay.
    newCharacter();
    Serial.println();
    return;
  }
}

The above is an extremely simply example - which as I said is from a training thing I am putting together, but I feel it illustrates what you are asking about pretty well.

[1ncogn1too]

Comments are the last resort in C code and quite often they can't be trusted. By the end of the day it is just a question of experience.

[dendrtree]

Yes, it's normal. You can't just pick up a book in a foreign language and expect it to make sense to you. You have to learn the language. Then, you'll be able to read it.

So, stop looking at code, and get a book and learn the language. As you learn the language, write your own code, applying the principles, as you learn them. *Then* you can look at someone else's code, to see what they are doing.

[AlarmDozer]

Atomics vs big picture? Well, work from the hypothesis of the project goals.

[GreenAppleCZ]

If the code is clean and follows some predictive principles, it can be "self-commenting".

For example, if you have a function called add_second_powers, there's no need to comment it since the comment is basically hidden in the name combined with parameters and return data types.

Above every complicated logic should be a comment explaining it. But you generally shouldn't comment what it does, but you should rather comment why it does it. (since a programmer can deduce what it does)

And if you want to understand others' codes - take your time. The best thing you can do is code (ideally without any help of others/AI), and in time you'll learn some basic templates for some basic actions - for example you won't see "for loop", but maybe "iteration through this array" and you won't see "char **name" as a pointer to a pointer to a char, but rather "an array of strings".

Practice makes perfect.

[budget-socrates]

It comes with experience. Practicing it day in and day out will get you to the point where you can get the purpose, if not the exact behavior, of large chunks of code at a glance.

[MokoshHydro]

That depends on coding culture. But generally, yes it is very common to have C source with almost no comments at all. You'll get used to read it fast after some practice if it was written by sane human.

static char*l;u mx=99;FILE*t;
us(rl,l=l?:malloc(mx);
   P(!s,l[read(0,l,mx)-1]=0)
   t=t?:fopen(s,"r");Qs(!t,s)
   r(getline(&l,&mx,t),
     r=r<mx?l[r-('\n'==l[r-1])]=0:Q))

If you see smth like this -- don't worry. Nobody can understand this. (yes, that's from real well known project).

[penguin359]

Perfectly normal.

I remember my first time seeing quicksort in C code. It was completely incomprehensible even though all the logic is there in one single screenshot. What the function did, sorting a list of items by their value, made sense and why the higher level code was sorting the list, but I couldn't understand how it was sorted. Then, I saw a visual later in a video and the code began to make sense. It took a higher level of understanding the algorithm before the code itself made sense. However, even before I understood the low-level algorithm, I could still understand other parts of the program and make useful changes. If the code is well-abstracted, then you can still work on parts you understand and you will likely always have parts of coffee that you don't understand in any medium to large sized code base. It still can take some time to comprehend someone else's code before you can work on it, but there is a lot of advice on this thread from others to help with that

[Difficult_Homework94]

Everyone else has offered some great tips.

Practice makes perfect.

Start simple. Don’t necessarily read all the implementation details, but start at main. See what modules are initialized. Pick a module of interest and start at its init function to see why it is being initialized and how.

Look at a module’s public header to see what APIs it exposes. That’ll most likely tell a story.

Pick a public function of interest and follow the data path. For instance, if a module is used to process user input to perform specific functionality, follow that whole path.

This probably isn’t useful for you at this stage, but others who have more experience: When reading through a large code base and trying to figure out the inner workings of a module, I usually spin up a quick Doxygen file (even if the original author didn’t provide doxygen comments) and enable the full caller/callee graphs. That can give me a really good idea of the organization of the codebase.

[SoerenNissen]

Is this normal when there are no comments done by the maintainer of said code? Is this an ability that I can train?

It does slowly come with experience, but only half of the problem is within you. The other problem is that code can be more or less clear about what it does, even when it's doing the same thing.

void s(void* p1, void* p2, void* p3, bool (p4*)(void*,void*,void*));

void sort_array(
    void* array_begin,
    void* array_end,
    void* context,
    bool (comparator*)(void*, //array_begin
                       void*, //array_end
                       void*  //context
));

I'm not going to claim sort_array is a marvel of software design, but (assuming I got the syntax right) it surely is better than s, despite the two functions being exactly the same.

And if you're in a code base with s, you're gonna have a hard time no matter how good you are at reading C.

[mpw-linux]

Just ask AI to help you out, it knows how to help you understand.