Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzy matching, hints, and solutions in verbatim steps #94

Closed
alexmojaki opened this issue Oct 21, 2020 · 0 comments · Fixed by #399
Closed

Fuzzy matching, hints, and solutions in verbatim steps #94

alexmojaki opened this issue Oct 21, 2020 · 0 comments · Fixed by #399
Labels
discussion Looking for ideas and opinions

Comments

@alexmojaki
Copy link
Owner

Most steps in the course are verbatim steps, meaning the user has to enter exactly the code they are told to. 'Exactly' means that the AST must match - there can still be differences in whitespace, the type of quotes used, or comments, but the structure and logic must be identical. There are some problems with this:

  • We want users to type code in, rather than copy and pasting it. If they type something in incorrectly, they don't get any feedback. We could perhaps do some kind of fuzzy matching between the user's code and the expected code. If they're very close, we could show a message indicating which parts of their code don't match. However we have to be careful to do this unobtrusively because they might just be experimenting with some code they wrote in a previous step before tackling the current step, which we want to encourage. Perhaps the hint bulb could suddenly appear and clicking it would show them the problem.
  • Sometimes the code they need to type in isn't directly shown, when users are told to make a small change to existing code. We don't show the code because it would add redundant clutter and would lead to more mindless copying instead of thinking about what they're changing. But if they misunderstand the instructions, they're stuck. These steps generally don't have hints and thus users can't access the solution. In any case the usual solution reveal would be out of place, we would probably just want to show the whole thing immediately. But to avoid people jumping to this, maybe it should only show after 2 failed attempts?
  • Steps often start with declaring some 'input parameters'. For example in this step:
        sentence = 'Hello World'

        include = False
        new_sentence = ''
        for char in sentence:
            if include:
                new_sentence += char
            include = True

        print(new_sentence)

sentence is a parameter, and users shouldn't have to write it exactly. In fact exercise steps already allow this. In most cases, the same flexibility would be good in verbatim steps.

  • Similarly, maybe variable names could be flexible?

These kinds of flexibility already exist in a couple of ways:

  • If you type in everything correctly except the case is wrong, e.g. something is uppercase when it should be lowercase, there is a message warning about case sensitivity in Python.
  • If you type additional statements after the part you're supposed to type in, they're ignored and you still pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Looking for ideas and opinions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant