Skip to main content
added 133 characters in body
Source Link
Jerry Coffin
  • 34.1k
  • 4
  • 77
  • 145

I think if I were doing this, I'd do it...somewhat (a lot?) differently. My immediate reaction would be to do something on this general order (using C++ syntax instead of Java, but I'm pretty sure the same basic idea should work in Java about the same way):

char gen_rand(std::string const &input) { 
    // A quick and dirty method, for now.
    return input[rand() % input.size()];
}    

static const string lower_c = "bcdfghjklmnpqrstvwxyz";
static const string upper_c = "BCDFGHJKLMNPQRSTVWXYZ";
static const string lower_v = "aeiou";
static const string upper_v = "AEIOU";

charstring gen_randgenRandomString(std::string const &input) { 
    // A quick and dirty method, for now.
    return input[rand() % input.size()];
}    

string output; // I suppose needs to be a StringBuilder in Java

    for (char ch : input_stringinput)
        switch (ch) {
        case 'c': output.push_back(gen_rand(lower_c));    break;
        case 'C': output.push_back(gen_rand(upper_c));    break;
        case 'v': output.push_back(gen_rand(lower_v));    break;
        case 'V': output.push_back(gen_rand(upper_v));    break;
        default: throw std::runtime_error("Unexpected character in input");
        }
     return output;
 }

If I'm allowed to speak in generalities, your code seems (to me) to spend a lot of effort on issues that are almost incidental to the question at hand (e.g., 37 lines just to decide that c, C, v and V refer to lower- and upper-case consonants and vowels). At least as I see things, the fact that the case of the input corresponds to the case of the output is really mostly incidental--they could just as well be a, b, c and d instead.

Another option that seems obvious to me, would be to use a map to take an input character and retrieve the collection of characters to choose from for that input. This is probably more work than it's worth for only 4 fixed inputs, but if you might have a lot of inputs, or (especially) if you want to support those inputs being specified at run time (e.g., reading them from a configuration file) a map becomes much more attractive.

Bottom line: it's a lot simpler and more flexible to just treat the mapping from input character to action as entirely arbitrary rather than go to a lot of work to classify the inputs as upper/lower case.

I think if I were doing this, I'd do it...somewhat (a lot?) differently. My immediate reaction would be to do something on this general order (using C++ syntax instead of Java, but I'm pretty sure the same basic idea should work in Java about the same way):

static const string lower_c = "bcdfghjklmnpqrstvwxyz";
static const string upper_c = "BCDFGHJKLMNPQRSTVWXYZ";
static const string lower_v = "aeiou";
static const string upper_v = "AEIOU";

char gen_rand(std::string const &input) { 
    // A quick and dirty method, for now.
    return input[rand() % input.size()];
}    

string output; // I suppose needs to be a StringBuilder in Java

for (char ch : input_string)
    switch (ch) {
    case 'c': output.push_back(gen_rand(lower_c));    break;
    case 'C': output.push_back(gen_rand(upper_c));    break;
    case 'v': output.push_back(gen_rand(lower_v));    break;
    case 'V': output.push_back(gen_rand(upper_v));    break;
    default: throw std::runtime_error("Unexpected character in input");
    }

If I'm allowed to speak in generalities, your code seems (to me) to spend a lot of effort on issues that are almost incidental to the question at hand (e.g., 37 lines just to decide that c, C, v and V refer to lower- and upper-case consonants and vowels). At least as I see things, the fact that the case of the input corresponds to the case of the output is really mostly incidental--they could just as well be a, b, c and d instead.

Another option that seems obvious to me, would be to use a map to take an input character and retrieve the collection of characters to choose from for that input. This is probably more work than it's worth for only 4 fixed inputs, but if you might have a lot of inputs, or (especially) if you want to support those inputs being specified at run time (e.g., reading them from a configuration file) a map becomes much more attractive.

Bottom line: it's a lot simpler and more flexible to just treat the mapping from input character to action as entirely arbitrary rather than go to a lot of work to classify the inputs as upper/lower case.

I think if I were doing this, I'd do it...somewhat (a lot?) differently. My immediate reaction would be to do something on this general order (using C++ syntax instead of Java, but I'm pretty sure the same basic idea should work in Java about the same way):

char gen_rand(std::string const &input) { 
    // A quick and dirty method, for now.
    return input[rand() % input.size()];
}    

static const string lower_c = "bcdfghjklmnpqrstvwxyz";
static const string upper_c = "BCDFGHJKLMNPQRSTVWXYZ";
static const string lower_v = "aeiou";
static const string upper_v = "AEIOU";

string genRandomString(std::string const &input) { 
    string output; // I suppose needs to be a StringBuilder in Java

    for (char ch : input)
        switch (ch) {
        case 'c': output.push_back(gen_rand(lower_c));    break;
        case 'C': output.push_back(gen_rand(upper_c));    break;
        case 'v': output.push_back(gen_rand(lower_v));    break;
        case 'V': output.push_back(gen_rand(upper_v));    break;
        default: throw std::runtime_error("Unexpected character in input");
        }
     return output;
 }

If I'm allowed to speak in generalities, your code seems (to me) to spend a lot of effort on issues that are almost incidental to the question at hand (e.g., 37 lines just to decide that c, C, v and V refer to lower- and upper-case consonants and vowels). At least as I see things, the fact that the case of the input corresponds to the case of the output is really mostly incidental--they could just as well be a, b, c and d instead.

Another option that seems obvious to me, would be to use a map to take an input character and retrieve the collection of characters to choose from for that input. This is probably more work than it's worth for only 4 fixed inputs, but if you might have a lot of inputs, or (especially) if you want to support those inputs being specified at run time (e.g., reading them from a configuration file) a map becomes much more attractive.

Bottom line: it's a lot simpler and more flexible to just treat the mapping from input character to action as entirely arbitrary rather than go to a lot of work to classify the inputs as upper/lower case.

Source Link
Jerry Coffin
  • 34.1k
  • 4
  • 77
  • 145

I think if I were doing this, I'd do it...somewhat (a lot?) differently. My immediate reaction would be to do something on this general order (using C++ syntax instead of Java, but I'm pretty sure the same basic idea should work in Java about the same way):

static const string lower_c = "bcdfghjklmnpqrstvwxyz";
static const string upper_c = "BCDFGHJKLMNPQRSTVWXYZ";
static const string lower_v = "aeiou";
static const string upper_v = "AEIOU";

char gen_rand(std::string const &input) { 
    // A quick and dirty method, for now.
    return input[rand() % input.size()];
}    

string output; // I suppose needs to be a StringBuilder in Java

for (char ch : input_string)
    switch (ch) {
    case 'c': output.push_back(gen_rand(lower_c));    break;
    case 'C': output.push_back(gen_rand(upper_c));    break;
    case 'v': output.push_back(gen_rand(lower_v));    break;
    case 'V': output.push_back(gen_rand(upper_v));    break;
    default: throw std::runtime_error("Unexpected character in input");
    }

If I'm allowed to speak in generalities, your code seems (to me) to spend a lot of effort on issues that are almost incidental to the question at hand (e.g., 37 lines just to decide that c, C, v and V refer to lower- and upper-case consonants and vowels). At least as I see things, the fact that the case of the input corresponds to the case of the output is really mostly incidental--they could just as well be a, b, c and d instead.

Another option that seems obvious to me, would be to use a map to take an input character and retrieve the collection of characters to choose from for that input. This is probably more work than it's worth for only 4 fixed inputs, but if you might have a lot of inputs, or (especially) if you want to support those inputs being specified at run time (e.g., reading them from a configuration file) a map becomes much more attractive.

Bottom line: it's a lot simpler and more flexible to just treat the mapping from input character to action as entirely arbitrary rather than go to a lot of work to classify the inputs as upper/lower case.