-
-
Notifications
You must be signed in to change notification settings - Fork 182
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
Why not always provide header for client? #252
Comments
@patricksjackson @wolf99 what are your thoughts? I think we had this discussion before but can't remember why we decided not to provide a header. |
Typically we provide the header if it's the first problem (hello world) or if it's not obvious what the header needs to be from the test file (see the struct definitions in anagram). I would bet that there are at least a couple problems where the necessary header content is really not obvious from the test file though, so just giving all the headers would certainly make things easier. The problem is we have to walk the line of helping out enough to be 'beginner friendly', yet not taking away too much of the problem solving. If we provided all the headers then we would never be forcing a student to ask "What type should this argument be?". The test files can't always let that be a choice, but we really want students to be asking those questions early, as long as it doesn't turn them off from continuing. So there is value in learning how to reverse engineer an interface from the test file, and there are several best practices unique to headers that are easier to learn after somebody points them out to you in code review (but you'd probably ignore if we just gave the header). For example, header guards and const'ness in the function definitions. That said there'd probably be less friction if we just included them all, but that doesn't necessarily mean it'd be better :) (It's been quite a while since I learned C, so I don't know how prohibitive 'figuring out the headers' actually is, and you can take my opinion with a grain of salt.) |
Issue #43 discussed this previously. It occurs to me that to for students to experience the full design decision process there should be a some subsequent point at which they are asked to write the test file itself also! AFAICT though this would be unfeasible for the language track infrastructure to handle. |
I can't recall if the README's provide any hints about this for the first exercises that require it. @jocal17 do you recall which exercise you found this to be an issue? It might be worth providing some hand-holding for the first one or two. The Java track has done something similar recently, exercism/java#1075 |
It was the second exercise, isogram. Since all other exercises I've done provided a starting file my first thought was that the isogram one was broken. |
Would this have been due to the exercise reordering? Or is it intentional that later exercises provide stubs? (maybe to help in more complex exercises) |
It was intentional in the other exercises. As far as I can tell they are provided for all exercises. They were Haskell and Python so somewhat different, though Haskell also provides the function types. |
The current core exercises with stubs, in current order of curriculum is listed below, basically only Following just the core, IMO it seems the jump to no provided header may now happen a little early in the case that a student is very new to C. Maybe we should provide a header for
|
I think that sounds reasonable |
I'll start working on a PR for this soon then 😃 |
Fixed by #255 |
How about changing exercise anatomy to
+--
+-- makefile
+-- src
| +-- example.c
| +-- .h
Since the client always needs to now what the test is expecting, why not either always make them check the test or always have header included? The latter seems better since exercism advertises as beginner friendly.
The text was updated successfully, but these errors were encountered: