read 2nd or 3rd line in txt file?

This is a discussion on read 2nd or 3rd line in txt file? within the C Programming forums, part of the General Programming Boards category; This is one question that I have asked myself a lot but I can never actually answer it. I have ...

read 2nd or 3rd line in txt file?

This is one question that I have asked myself a lot but I can never actually answer it. I have ran it through my head made some stuff up that might work but has a few problems and some other things that are very "what was i thinking".
My question: how do I read a certain line in a text file.
It seems like I am not getting the very obvious solution.

If you could tell how most people go around doing this by typing some pseudocode or something that would be awesome.
(I do NOT want your whole program. pseudocode is enough for me).

I have started on my code, and I am getting some weird results.
The application doesn't actually go into the while loop. If you could help that would be cool.
(It might be some simple thing I overlooked).

Code:

#include <stdio.h>
main()
{
int line = 0;//tell what line it is on
char liner[100];//put the characters of the line into here
int linesearch;//the line you are looking for
FILE *file;//the file pointer
file = fopen("search.txt","r");//point the file
printf("line number:");//print line number...
scanf("%d",&linesearch);//...then scan after the printf
printf("going to line %d",linesearch);//to make it look like programs in TV shows
while(fgets(liner,100,file))//read the file string by string
{
printf("%d",line);//when a line is read tell what line it is for debug perposes.
line++;//make 'line' go up once
}
getch();//getch to see what was printed out.
}

#include <stdio.h>
main()
{
int line = 1;//tell what line it is on
int found = 0;
char liner[100];//put the characters of the line into here
int linesearch;//the line you are looking for
FILE *file;//the file pointer
file = fopen("C:\\Users\\bob\\Desktop\\hl2\\portal_config.cfg","r");//point the file
if (file == NULL)
{
printf("file does not exist or doesn't work\n");
return 0;
}
printf("line number:");//print line number...
scanf("%d",&linesearch);//...then scan after the printf
printf("\ngoing to line %d\n\n",linesearch);//to make it look like programs in TV shows
while(fgets(liner,100,file))//read the file string by string
{
if(linesearch == line)
{
found = 1;
printf("line %d found,line %d says: %s",linesearch,linesearch,liner);
}
printf("reading line: %d\n",line);//when a line is read tell what line it is for debug perposes.
line++;//make 'line' go up once
}
if (found == 0)
{
printf("line number %d was not found",linesearch);
}
line = line - 1;
printf("\nthis file has: %d lines",line);
getch();//getch to see what was printed out.
}

What I'm pointing out here is not an error, but rather an issue of style.

Commenting code is definitely a useful endeavor, and I'm glad to see that you're doing it. However, the art of the comment takes some time to master. Your comments should not simply restate, in English (or whatever language) what the code is doing:

Comments like these do not help the reader understand what is going on. Either he knows C, and the comments are redundant, or he doesn't, and the comments won't help him at all (and comments really shouldn't be aimed at those who don't know the language...)

Instead, comments are more usefully employed to explain, say, the arguments to a function (can this pointer be NULL? what is the valid range of this data type? and so on); a high-level description of an algorithm; an explanation for something that might appear sketchy or wrong; and so on. Assume the user understands the code itself, but perhaps not why you put it together the way that you did.

As an example, here is a comment I pulled from a project of mine. This comment describes a table (that is, an array) that maps one value to another:

Code:

/* The null character in the alphabet table does not actually
* signify a null character: character 6 from A2 is special
* in that it specifies that the next two characters form a
* 10-bit ZSCII character (§3.4). The code that uses the
* alphabet table will step around this character when
* necessary, so it’s safe to use a null character here to
* mean “nothing”.
*/

I think this is a useful comment because it explains a quirk in the table (one of the entries isn't really supposed to be used), which hopefully will avoid confusion. In addition, it makes a reference to a specific chapter in a standards document so the reader can verify/look up what, specifically, is being worked around. The name of the document is not mentioned, but for this project that's OK, because it's an implementation of that standard and so is implied.

There was nothing wrong with the commenting in ninja's code - perfectly understandable - in fact a lot easier to get through than the so called style approach. Remember less is more in programming.

I'm always willing to incorporate new things I learn if I find them to be superior to what I'm doing. So can you articulate what it is about a comment like “make 'line' go up once” that you find useful, when accompanying the code “line++”? I see absolutely no benefit, but if you can tell me what the benefit is, I'm willing to listen. Note that I'm not saying the comments are wrong, or not understandable, but that they're redundant.

Thanks I will try taking your commenting style into effect with my next projects. But when I posted the code I didn't have any errors (with the code) that I was seeing, I just wanted to know if i made a noobish mistake.

When I write comments, I'll write comment blocks on the intention of the block of code. Inputs, outputs, return codes, and a higher level answer to the question "what is this routine's purpose in life?".