I have this code

     #include <stdio.h>
     #include "ctype.h"
     #include <string.h>
     #include  <stdlib.h>
    #include <string.h>

    char p;
int j;
int i;
FILE *f1;
char c;
int main()

 {
f1 = fopen("ard.txt","r");

if(f1 == NULL)
{
    printf("No se ha podido abrir el archivo");

}
        while((c=fgetc(f1))!=EOF)
 {

if (isdigit(c))
{
    putchar(c);
}
else if (isspace(c))
{
   putchar('\n'); 

else if(isalpha(c))
{
   putchar(c);
}
else if (isspace(c))
{
   putchar('\n');
}
}
}

And the txt file is it:

  1234 234 
  34 j4 
  j5544  555 jose

and the output is it:

1234 
234
34 
j4

j5544

555  
jose

the line between words should not leave

I need the output to be the next

1234 -------- number
234 --------- number
34 ------------- Number
j4 -------------- identifier
---------------------------- This line should not leave
j5544  -----------identifier
 ---------------------------------- This line should not leave
  555 ------------   Number
 jose ------------ word

how I do that and that does not leave the line between them applied and that appears
LABEL TO EACH FOR EACH LINE THAT IS NUMBER, WORD OR IDENTIFIER

   

The coding is secondary to the algorithm in projects like these. This is a pencil and paper exercise till you figure out what process you want/need to use. A few things to consider...

  1. You need to determine exactly what you have to be able to handle in this program.
  2. You need to determine exactly what you DON'T need to handle in this program.
  3. You need to determine if 1 and 2 have been firmly established already or might change in the future.

In regard to number 1, that is what is "necessary". Your program must handle everything in 1. You have numbers, words, and identifiers. You need to be able to handle those. These presumably have stringent definitions involved with them. You will use these rules to determine when you are "done" with a token.

In regard to number 2, that is what is "sufficient". Don't bother putting the time in to solve things that don't need to be solved. I don't see any parentheses or operators for example. If you know that you don't need to handle those, don't handle them. It's also nice to know whether if you run into something illegal, can you just abort everything and have a generic "parse error" printout or do you have to print out something more useful, give them hints, etc. Or maybe every single thing that is thrown at you will have no errors (highly doubtful).

In regard to number 3, often these types of projects are multi-stage and the teacher or project manager or whoever doesn't tell you all the stages in advance, so you have to find that out. If everything is known in advance, you don't have to worry at all about being flexible. But if not, you would not be the first person to create a fantastic algorithm for stage 1 and have to throw the entire thing out when you get to stage 2 and it's something you didn't exxpect to have to handle.

Coding is last. Get the algorithm down first and think how you would do it if you didn't HAVE a computer and had to write a term paper or a logic flowchart for the process. Think of points 1, 2, and 3 when designing the process and give yourself a bunch of different input files, some that break the rules and some that don't (again, find out what needs to be handled and how), with the mindset that it's your job to BREAK the algorithm.

You can't write the algorithm without understanding the "rules" first. You can't write the program without creating the algorithm first. The coding part is the EASY part.

Edited 3 Months Ago by AssertNull

Comments
+1 for noting we use our head first.