Skeleton files should be included in all problems to make it easier

[gytdau]

I'm on the Python section, and I've found that only a few challenges include a skeleton file. This is helpful, since you can then start coding without the delay of creating your own file. Example: the Bob challenge comes with bob.py:

#
# Skeleton file for the Python "Bob" exercise.
#


def hey(what):

    return

It'd be great if a skeleton file like this was included in all of the challenges, to make things just a little bit easier for everyone.

[behrtam]

I already had a similar feeling #210.

[kytrinyx]

We originally put stub files in early exercises because some people are stumped about how to even start solving the problem without a stub file in place.

However, I've found that one important part of TDD for me has been to recognize categories of errors. Recognizing the type of error that comes from a missing file and a missing constant or definition seems like a fairly important step to me.

I like stub files in the early problems to help people get started, but once they are confident, I find that stub files are training wheels that are no longer necessary.

[behrtam]

I see it exactly the other way around. While I agree that recognizing categories of errors is an important skill but once you have created 1-3 files and know how to find out the function signatures this task get's boring and is just an unnecessary step.

[gytdau]

In any case, I see creating the file as a mild annoyance. It would be nice if the file was created for you, but this is not a huge issue.

[behrtam]

I just started to work on the Scala track and it's really annoying to create the files. We should create them for all exercises. Mostly without any code, so we don't force specific ways of solving the problems.

[kytrinyx]

Do you mean completely empty files? Or with empty function definitions?

[behrtam]

The test suits define the class and/or function names, so I would add them as the developer has no choice about that. It's just tiring work that doesn't add any learning value.

[kytrinyx]

That sounds reasonable to me.

[lbain]

For what it's worth, I learned about how python file/function names can be imported from Exercism because the default file and functions weren't supplied. Hello World simply uses import hello_world and then explicitly calls hello_world.hello() from there. But the next exercise (leap year) uses from year import is_leap_year and it took me a bit of investigating to work out how it all fits together. Sure, it's probably less valuable after the first two or three, but needing to create new files did teach me something at first.

[Dog]

@lbain 's situation is why I've been resistant to including skeleton files. I wonder if it may be experienced more by people who have more experience with the programming language already. I felt keeping skeleton files out at least forces people to figure out how imports work, and it becomes less of an issue later on when exercises get more difficult.

[tewe]

Having stubs would take the fun out of exercises that require special method names, like Clock.

How about storing the file name in the exercise? Then exercism submit wouldn't have to ask and a new exercism edit could launch an empty $EDITOR.

[arcuru]

@tewe Those may be good suggestions for the client, as the client would have to build those in before we used it here, and I'm not familiar enough to know why they chose not to do that.

May be a good question for https://github.com/exercism/cli

[pheanex]

Let's get this started -> #415 Please Review
@tewe I also renamed the files such that the name of the test- and implementation-files can be deduced from the exercise-name
I'm with @gytdau and think adding initial/minimal skeleton files makes it more convenient for people to get started with a new exercise and removes the boring/repititious task of creating new files. So they can get started right away and have fun doing the actual exercises.

[behrtam]

We can create any empty file which is required due to being imported in the test file, that makes sense to me. But having every exercise already started with a class, function or what ever doesn't look like a good idea to me ...

[pheanex]

what about your argument on on 14 Apr 2016 here?

[behrtam]

To explain my schizophrenic self. Let's take the luhn exercise as an example. Right now we only provide the test file with the line from luhn import Luhn. So, we should definitely provide a luhn.py file, no question about that. But how much more should be thought about carefully. Options would be ...

• an empty file

• a minimalistic class

class Luhn(object):
    pass

• a class with all methods

class Luhn:
    def __init__(self, number):
        pass

    def addends(self):
        pass

    def checksum(self):
        pass

    def is_valid(self):
        pass

    @staticmethod
    def create(n):
        pass

To provide the full structure, all function parameter names, etc might be a good idea for some exercises (especially for the first exercises), but I won't do it for all. Coming up with good parameter names, understanding the test suit and what needs to be implemented should be part of the learning experience as well. So, I would go with the minimalistic class and if the task is to implement functions, I would leave out the parameters in the stub file.

[tewe]

I vote for the empty file. People should be free to satisfy an API expecting a class with a function (or a duck) of the same name.

[pheanex]

one advantage of already providing the names would be more comparable solutions. But i can also the advantage of it being part of the exercise, although a bit strenouos if you do more exercises in a session.
=> How do we decide? Is it by voting or does @behrtam pick one?

[tewe]

I want diverse solutions, not comparable ones.

[pheanex]

=> Fallback: Finding decision by default: "By voting" => 2/1 for minimal-skeletton-files
=> I updated the PR => Please review again.

[iHiD]

With reference to this discussion, you may want to consider https://github.com/exercism/exercism/issues/4789