0

My Code:

int main(int argc,string argv[])
{   // Checks if the program got an agrument
    if (argc != 2)
    {
        printf("Pls dn't spuk teh prgoram");
        return 1;
    }
    else
    {
        // The command line argument is equal to the cipher
        string cipher = argv[1];
        string text = get_string("Plaintext:  ");
        int w = 0;
        for(int i = 0;i < strlen(text);i++)
        {
            char minus = toupper(cipher[i])-65;
            // Equal to cipher length minus one
            int cLength = i % (strlen(cipher));


            // checks for non numbers
            if(isalpha(text[i]) == false)
            {
                printf("%c",text[i]);

            }
            else if(i < strlen(cipher))
            {
                // For looping  the letters in case it would be larger than z
                if((toupper(text[i])+minus)>90)
                {
                    printf("%c",text[i]-26+minus);
                }
                else
                {
                    printf("%c",text[i]+minus);
                }

            }
            // This is looping the cipher
            else
            {
                if((toupper(text[i]) + cipher[cLength]-65) > 90)
                {
                    printf("%c",text[i]-26 + cipher[cLength]-65);
                }
                else
                {
                    printf("%c",text[i]-26 + cipher[cLength]-65);
                }

            }

        }
    }
}

The problem with my code is that I can't figure out how to continue getting the right cipher after a space is included

for example: key: bacon Meet me turns into Negh tk when it should be Negh zf

I know why it fails

It fails because the space increments the cipher up one so instead of applying n it applys b. I'd appreciate any help.

3

This is a common error on this pset. The code needs two independent index variables to track the position within the plaintext and the key. You have two vars, i and cLength, but they are not independent. cLength is 100% dependent on i.

Here's why. The plaintext index var, i, is incremented for every letter processed for the plaintext. However, cLength, the index var for the key, should only be incremented when a letter is encoded and never incremented when a non-letter is processed.

The two vars need to be decoupled.

As a side note, let's talk about the very first if/else condition. The if portion is fine. However, including an else clause is a bad practice here. If the IF clause is true, the program will terminate. If false, the program will continue and execute the remaining program code.

The main reason that the else clause is bad is that it will encase the rest of the program. If the program needs to be altered or updated at a later date, a new programmer (or even the original author) may not catch the location of the end point of the else clause. This leads to the heightened possibility of adding a logic error later.

In short, the else clause is unnecessary code in this scenario and introduces future opportunity for error. Best practice is not to use it with an IF statement when testing input data validity.

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)

0

You need a variable to walk through the plaintext. And you need a variable to cycle through the key.

Those two variables don't have to be the same variable ...


And to quote Cliff B:

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)

11
  • It isn't that they "don't have to be" the same, they must not be the same.
    – Cliff B
    Oct 25 '18 at 2:12
  • Correct. But I didn't want to give a full answer. It's easiest to simply use 2 different variables for this. But I see some students using a variable which counts how often they skipped a character. That makes the code hard to maintain, but strictly spoken it's not incorrect ... Oct 25 '18 at 2:23
  • True. But let's go further with that. Those "some students" usually employ complicated mechanisms to track when non-alphas are processed, either by additionally incrementing a second var that is still coupled to the plaintext index, or by using a third variable to track the number of non-alphas processed. So, as you said, it gets overly complicated, hard to maintain, and introduces opportunities for error. It's always best to just keep it simple! So, it's best to fully explain to new programmers while they're learning before they learn bad habits. ;-)
    – Cliff B
    Oct 25 '18 at 2:50
  • Agree. But I always find it very difficult to explain why something is bad without showing a good example. And showing good example always has the risk of imposing our coding style. (Sorry, don't know how to say that in English in a few words) Oct 25 '18 at 3:07
  • ... the risk of imposing my coding style on them ... Oct 25 '18 at 3:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .