I've read countless articles, forum posts, etc on this, like for example, following the main() function, but I still get lost every time. It's not so bad when it's code I've written, because I know what I was thinking at the time, or at least what I was trying to do. But when it comes to code written by others, even if I know what the program does when I run it, I still get completely lost trying to read and understand it, even if it's in C and is using concepts and constructs I've familiar with. It might be ok if it's the whole of two lines, and/or it just adds two numbers together and displays the result and that's about it. But anything even just semi-complex is like trying to read a spoken language I just don't speak or know any of.

But yet, if it's trying to figure something out at a "high level", like for example solving non-programming related technical problems, like general Linux problems for example, then I can 9 times out of 10 figure it out and solve it. If I read someone's post here where they're asking for help with some Linux problem (or sometimes non-Linux related technical problems too) I can read their post(s), follow what they're saying, and normally figure out at least where things are likely going wrong for them (provided it's a technical related subject I'm familiar with of course - can't claim to know everything), and at least most of the time, help them figure out a solution to it. A very recent example of what I'm saying, and in relation to a problem I was having (but didn't need to post a thread asking for help myself about); I very recently upgraded my system to OpenMandriva Lx 4.2 from 4.1, but it took three go's to actually not only get it installed, but get a working system. The first problem was that, I told it's installer to just format my root partition, and just add an entry to fstab for my home partition, but while it did do that, upon system restart it would drop into an emergency shell and wouldn't ask for my LUKS encryption password (as I encrypt my home partition, but not the root partition - since there's nothing sensitive on that). So I thought hmmm, wonder if the installer actually added my home partition to fstab? So I had a look at fstab, and yes it did, but it didn't specify any actual node, just the path to the node, but no device node (the device-mapper node). So I thought, "well I was thinking about repartitioning the drive anyway, so I'll just copy what's on my current home partition to my other drive, and repartition", so I did just that, and then set the relevant mount points in the installer. Then I restarted the machine again after the installer had said that OpenMandriva had been installed, and my machine booted into the UEFI BIOS settings instead. So I had a look at the boot order and there were no boot entries listed, so I booted back into the live system and had a look with efibootmgr, and that reported zero boot entries in NVRAM. So I mounted the root filesystem on the partition I'd created before (that OpenMandriva was supposed to be installed to), and sure enough, it was empty. So I thought, "this time I'll mount the partitions I'd created beforehand, then run the installer to [hopefully] install OpenMandriva this time", so I done just that, then for the third time once again run OpenMandriva's joke of an installer. Then once that had said it had finishing installing OpenMandriva onto my machine, I once again restarted it, and voila! OpenMandriva was not only installed, but booted up no problems. The point is: troubleshooting that, and figuring out the chain of events was fairly easy, but I just can't seem to transfer that to following other people's code no matter how (or how hard) I try and follow it.

I'd just like some practical advice on how I can follow other people's code without getting completely lost - particularly where people have used meaningless variable names that don't describe said variable(s) purpose (which makes it a thousand times harder again). I'm not looking for a debate on the best way to read code either, just how exactly I can read it, so I can follow and understand it. While I'm mainly asking in relation to C (since that's about the only language I've made any serious attempt to try and learn), as long as it's still applies to C as well, any advice that helps would be good. I might be doing a programming course within the next 3 - 6 months sometime (although while I think it includes C# , sadly it doesn't look like it'll be in C itself), so I'd really like to try and get as much of a head start as I can if that comes about. I have also tried (as suggested by others in my other programming threads here) to get a better handle on mathematics as well, so hopefully I've done enough on that front.

Thanks in advance for any help/advice.

Doesn't all IDEs allow you to single-step through code?

Even those many years ago when I last coded, the editor had that life-sanity-saving ability to single-step while showing changing values of any selected variable...

2 members found this post helpful.

I think that your experience is typical.

The brain is wired to work in a certain way and expects to see problems solved in that way.

I can always figure out code that I have written, even decades ago. The old thought processes come back and I remember why I did things in that way.

Other people think differently. Their thought processes may or may not match mine. The quality of the code is also highly variable - occasionally it is well-documented, but often it is not.

I don't always expect to be able to figure out other people's code.

Programs tend to get rewritten every time new programmers come along. Starting over is sometimes easier.
Ed

1 members found this post helpful.

Yup, that's difficult. Where is the beginning? What calls the part that I am interested in? Even something with a small code base like this example:
https://github.com/epitron/dillo/tree/master/src
And that's a small/light/low depends little browser.

The easiest way would be to contact the developer and see if they will help steer you. If not, then you'll have to look at the code base and see what imports what from where. Then if the files are C C++ or Python, then you'll need to understand C or python of course. And that is even difficult. It takes years sometimes to get a good grasp on different programming languages. Especially if you are not a professional that does it every day.

I see projects that use C, C++ in them, that call on header files, that use gtk, Qt, fltk, tcl. That's a whole lot of stuff to learn. You'll need to read the docs on each of them. That's after you get a good grasp of them.

There are some tools that you can use to help. Python for example.
Look at Out.txt Or use an IDE like another suggested, but you still need to understand what is happening.

I'm not sure that there is an easy answer altering someone else's code base. Looking at someone else's code, broke up into 20 different modules, and trying to understand it, is just plain hard.

Being someone who does that, it is a hard thing to do. If it is important to you then you'll need to devote hours, weeks, months to it. You'll need to decide how important it is to you, and what the payoff is. Or, remake the functionality of it using something that you know. Something like python where functionality is already built in using different modules, and all you have to do is call parts of those modules, and feed them something, to do something.

Looking at the tree of w3m and lynx is difficult, and those don't even have GUI's.

Yes, but it may not be that easy. That works for smaller projects. Try to write a web browser from scratch in C, C++. Including the engine like dillo did, not just the GUI.

If you don't have the knowledge then using someone else's open source code and modifying it is what one would do. I assume that is what the OP wants.

I applaud the OP for studying this. It will take time and learning. The more you learn the easier it gets.

1 members found this post helpful.

They absolutely do allow this, and show backtrace, plus variable values. This is an excellent suggestion.

There are no fast shortcuts to being able to read and understand code. Everything in the language can be decoded and followed given enough time and effort.

2 members found this post helpful.

+1 for this advice.

Doesn't matter whose code it is...even if YOU wrote it and put it down for six months, chances are you'll have to thread your way through it again, and figure it out. This is why I heavily comment EVERYTHING I write, and it pays off. Every routine has a description on what it does, where it gets input, what it does with it, and where the output goes, and what other routines it touches. And I even comment lines/sub-sections too, just for those reasons. Takes time, but if you have to modify something later, it saves you a thousand times more effort than it took to put the comment in.

3 members found this post helpful.

Thanks guys. I wasn't ignoring anyone, I just wanted to wait for as many comments/advice as I could get before responding.

I do like the idea about an IDE to step through the code (I assume that means actually running the program while stepping through it), should have thought about that, but like the idea nonetheless.

I have commented a few things I wrote in C as learning exercises, but they were brief comments though - as I didn't want to "drown out the actual code itself" and make it harder to read. TB0ne, do you also comment each and every line, like for example, "initializing x variable with y value", then "if x variable has y value, execute if statement code block", etc, etc? Or do you just explain what said function (for example) does, the inputs, outputs, etc like you were saying above? As I'm just not entirely sure how far I should go, given that I've had both people here, and read elsewhere that too many comments is bad, and you shouldn't do it. Don't get me wrong, I can see a difference between code purely written as a learning exercise verses code written for production purposes. So I'm just wondering if you write long comments for both cases, or just the former (just to help your own learning rather than for others to read)?

Just to be clear, I wasn't expecting it to happen overnight, but I thought once I got more comfortable with the concepts, it would become easier to read not only my own code, but other people's code too. But it just doesn't seem to have worked out that way. As I'd like to be able to find and fix bugs rather than having to wait for someone else to do it, so it's just frustrating when I just can't seem to follow code, even when I do know what an if statement is, does, and looks like, or a structure, array, or whatever else.

How long have you been working with C for, and how many different pieces of software have you worked on?


Depending on the above, this might be a good thing - knowing more than one language should help to solidify concepts, though if you're still new to programming it might be better to focus more on one language first.

I started learning C at the end of 2018 or thereabouts, and as far as software I've worked on, I've only really written code as learning exercises apart from one program I managed to write (with some help from others here) that reads a config file, then passes arguments to ffmpeg (no GUI of any kind, just a command-line based program).

Although, and of late, I haven't done much programming, since I was trying to improve my mathematical skills to try and help with learning C and programming in general. But I think I've got at least a reasonable understanding of things like variables, if statements, arrays, structures, etc. Although, I wouldn't put myself in the "expert" category by any means, that said.

Yeah, that's inline with what I expected. Two years isn't a long time in programmer terms - even someone working full-time would still be considered a Junior Developer at that point - so more practise will definitely help.

Comments will not necessarily make you better at reading and following code - they might make code easier to follow, but that's not the same as making you better at following it.
Though putting thoughts into words can help - I've worked with developers who would write notes (in a paper notebook) to help them understand/navigate particular pieces of code. (The act of writing out anything helps with memory, but there's a difference between inline annotations and writing a summary/description for yourself.)

Another thing that can help is mapping out flow-charts (paper or digital) - doesn't need to be an exact replica using official symbols, just a few boxes and lines/arrows can be enough to start building a general mental model.

Also, it might be worth having a go at reading something written in C# or Python - even if you really want to work in C, if another language happens to gel with you more it may make it easier to develop the skills which you're then able to combine with your C knowledge.

1 members found this post helpful.

Another point about Integrated Development Environments (IDEs) is that when you have files included in a project or workspace and you find a reference that's not obvious or local to a file you can use the IDE capabilities to find where it is both referenced, and also where it is defined.

Some code published by persons (it all depends on how they developed it, and if they used an IDE for it and included this with their publication of code) will contain a project file typically for a certain IDE, but many times one which either can be converted or interpreted by other IDEs or the IDE they used is freely available.

Worst case is that you just take all the files in various directories under the top level and add them to an IDE project.

I tend to not rely on IDEs and instead use the command line.

My most favorite (out of date) command, still used, is:What that does is finds all files starting from where you are, of type C and H (and one can shape that search string however they want), and executes a grep within the found files for the string specified, that's what the {} does.

Long ago I posted that and someone suggested the /dev/null and explained it. It worked and I've long since forgotten how it omits some stuff from the output, I think junk intended for stdout that's either errors or superfluous "not found" reports, gets pushed to "nowhere" /dev/null and it merely cleans up the output. My fingers just type it really. As an example if the find command no longer needed a dash in front of the exec directive, you could tell me that till you're blue in the face, but I'll still type it.

What works for one person is not always suitable for others.

One example is my tired old command line tendencies, but ... also note that I understand modern IDEs, which means ... I've used them and understand how to employ their features. Preferences notwithstanding, if you are in one situation and cannot employ your preferential methods, be open to understanding other methods well enough to accomplish your intentions.

1 members found this post helpful.

Alternatively, install a tool like Ack and you can use:
I only mention it because that find command is an unnecessary mouthful - there's plenty of other grep-like tools that will do similar (maybe even work better), but further commenting on favourite searching methods would be going off-topic.

1 members found this post helpful.

Thanks boughtonp, I do find looking at flow-charts does help in understanding things - I've done that with other things and sometimes it was the only way it was clear to me how it worked (or at least what the "process" was). And maybe a combination of that and writing notes, along with an IDE seems like a good way to go.

It's funny you mention Python, as that's one of the other languages, from memory, that the course will be using. I have heard others say that's one of the easiest programming languages to learn, but since I've never tried to learn it before, I'll have to take their word for it for now. What language did you start out with if you don't mind me asking? And how long did it take you to be able to follow code?

Yes, that's one of the biggest problems (maybe even the biggest) I have with trying to follow code. In that, if something, for example, is defined in a header and it's referenced in a c source file somewhere (or vica versa), then I've got to scan through the header to try and find what I'm looking at, and that's when I just get completely lost trying to find where I was up to in the c source file, then having to try and remember what I'd read beforehand, then try and follow the rest of the code. It's like trying to find my way through one of those hedge mazes where there is only one way out, but several dead ends, and I just keep hitting dead end, after dead end, if you know what I mean. And for that matter, even just in terms of c source files without looking at any header files it's pretty much the same story.

While if it helps in the meantime, where I can at least be able to follow code, I'm happy to give an IDE a go to develop enough skill to be able follow the code; I'd really like to be able to get to a point where I don't need to rely on an IDE, and just use the command-line like you.

Understanding the code depends on the writer/maintainer and obviously on the reader.
This is just an example: https://www.ioccc.org/2020/endoh2/prog.c (see https://www.ioccc.org/)
An IDE can help you to follow the code, but first you need to know the language and also need to be familiar with that IDE.
With other words: you will be only able to use an IDE if you know what's happening in the background and if you could do that without that IDE too.
(but obviously that IDE will speed up things)

1 members found this post helpful.

Difficult to say how long - I started with various versions of BASIC as a kid - had a ZX Spectrum at home, and used RM BASIC to write a bunch of games during lunchtimes at school. (It'd be fun to see the code I wrote, but I don't even know where the floppies are now, nevermind if they'd even work.)

My first "serious" application was probably in Delphi (Object Pascal) - the way the IDE linked the GUI/attributes and action code plus the event-driven nature of the language made it easy to follow what was going on - significantly easier than when I later started trying to understand PHP applications.

I didn't have a problem handling the various codebases of my first full-time job, but I'm not sure how to quantify my experience up to that point.


That has reminded me of another point - software written against any good framework has potential to be easier to follow than something that has grown without discipline. A lot of earlier PHP applications were basically a bunch of scripts connected via includes without good structure, which was a big part of what made it harder to decipher.

Frameworks help combat that - whilst there are times when they add unnecessary complexity (especially when misused) - but in general having a clearly defined structure, one that can be learnt independently of understanding the application itself, will help to follow what is happening without getting lost.

1 members found this post helpful.