Often we find questions along the lines of
Help me understand this C program
#include<stdio.h> main() { printf("Hello World"); }
Well, that one may be a bit simplified - but its not an uncommon form for a question that is asked here.
How should one prepare and ask a "what does this code do" type question?
Often these questions are closed.
In days of old they would have been closed as "not a real question" or "too localized." The reasoning behind this is that there isn't really anything that one can answer definitively and draws upon our expert knowledge as a programmer. Furthermore, there are an endless stream of these small programs or snippets of code to be explained. The way the question is asked and its difficulty being findable and useful to other people made it too localized.
Today, these questions often are closed as "unclear" or "too broad." It is unclear exactly what the person is trying to get out of the question and how our answer can actually be helpful to them (it may be at too low a level, or too high a level, we don't know what the user knows (do they understand arrays? are they trying to understand variadic functions? standard lib IO call? etc...) To properly explain all of this at all levels is at the level of a semester long class at the college level or a number of chapters in a "teach yourself C in 21 minutes" book.
One of my favorite essays on programming is that of How to be a Programmer: A Short, Comprehensive, and Personal Summary by Robert L Read. The first item under the skills for a beginner is Learn to Debug which starts out:
Debugging is the cornerstone of being a programmer. The first meaning of the verb to debug is to remove errors, but the meaning that really matters is to see into the execution of a program by examining it. A programmer that cannot debug effectively is blind.
Idealists that think design, or analysis, or complexity theory, or whatnot, are more fundamental are not working programmers. The working programmer does not live in an ideal world. Even if you are perfect, your are surrounded by and must interact with code written by major software companies, organizations like GNU, and your colleagues. Most of this code is imperfect and imperfectly documented. Without the ability to gain visibility into the execution of this code the slightest bump will throw you permanently. Often this visibility can only be gained by experimentation, that is, debugging.
These questions of "explain this code to me" is very much akin to someone coming up to you, handing you a picture
Image from draw an elephant
and saying "I don't understand this. Could you describe what you see here?"
There are so many possible options for someone to describe. We could describe the process of drawing (and you can see the sketch marks from previous revisions). We could describe the elephant itself and its form. We could describe the technique (and if we think its good or bad). The possibilities are endless.
However, in doing this - you aren't seeing it. You are listening to what we are saying (one would hope), but not actually going through the process of figuring it out yourself.
It is that process of learning how to see the code that is critically important for a programmer. For us to describe it to you deprives you of an opportunity to learn how to use debugging tools. It deprives you of attempting to get that process in your own mind.
One of the things to realize is that walking through rudimentary code and explaining it line by line is kind of boring. Its something that you can do with a debugger - often available and integrated with the IDE you are likely using.
Show what your understanding of the code is. Are you confused about how printf() takes one argument in one example and five in another? About why some people write for(;;)? Demonstrate that you have used the tools that are available to you to the best of your ability (and if necessary, read the tutorials for the debugger).
If, for some reason, you don't have access to a debugger, learn how to print debugging statements and trace them out. If necessary write a program that does the minimal number of lines and be sure to read the documentation for the function call you are about to ask about.
We are much more able to help you do the equivalent of spell out a word and understand its meaning rather than respond to a child coming up to us and saying "read me a story" and handing us a book. To the student coming up to us now and asking us to "read me a story" we are responding, "try to figure it out as much yourself on your own and ask about specific comprehension and vocabulary problems."
Further Reading
How to debug small programs
