Comments (9)
+1 I think this would be helpful.
from go.
Does this need to be done with every exercise? While I agree that providing a template would be helpful for the first exercise, providing the API's may accidentally discourage newbies from considering how to name the inputs and outputs of their functions.
If an API is provided for every exercise, then there needs to be more thought about the names used, especially if the existing examples are converted. Let's take the first exercise as an example:
func IsLeapYear(i int) bool
... was the API used in the example file. Should "i" be renamed "year"? Or "inputYear"?
Also, some of the example implementations make use of named results:
http://golang.org/doc/effective_go.html#named-results
The choice of whether to use that feature should be up to the participant, and providing an API might make some reluctant to take the alternate approach of returning results.
I think a compromise is to provide some tutorial comments with a first and only implementation template.
Something like:
// For each exercise, create an implementation file with the same package name as the provided tests.
package leap
func IsLeapYear(i int) bool {
// To run the unit tests, run "go test" in the exercise directory, without quotes.
// Many exercises come with benchmarks, which can be run with "go test -bench ."
// Use the unit test results and the tests themselves to determine which function API's to implement.
// Please run "go fmt" on your code before submitting it.
}
The potential downside of such tutorial comments is that they need to be maintained, along with the existing exercism help documentation. That, and the first exercise could change with the config.
from go.
Another quirk with providing a template and API:
Travis CI currently fails if both the example and template implementations exist in the repository, due to multiple declarations.
Continuing with the "leap" example, example.go and leap.go would collide with each other:
leap/leap.go:4: IsLeapYear redeclared in this block
previous declaration at leap/example.go:3
https://travis-ci.org/exercism/xgo/builds/31483810
from #98
This could change, but it's another thing to consider.
from go.
I hear you, regarding naming the arguments, the following code is valid:
func IsLeapYear(int) bool {
// TODO: implement
return false
}
I'm not sure that all exercises need that but in this specific exercise it
makes things easier for first time users.
On Aug 2, 2014 1:14 AM, "Alan Shen" [email protected] wrote:
Another quirk with providing a template and API:
Travis CI currently fails if both the example and template implementations
exist in the repository, due to multiple declarations.Continuing with the "leap" example, example.go and leap.go would collide
with each other:leap/leap.go:4: IsLeapYear redeclared in this block
previous declaration at leap/example.go:3https://travis-ci.org/exercism/xgo/builds/31483810
This could change, but it's another thing to consider.
—
Reply to this email directly or view it on GitHub
#97 (comment).
from go.
That works. Still need to consider the case where Travis tries to test out both example.go and leap.go. Is changing the Travis CI behavior worth it for one exception? Or would it be better to figure out a workaround?
from go.
The idea of providing the API has come up before. Some exercises currently have the API documented in comments in the test code and the Go help page says to read the test code. We could add similar comments for Leap, but I'm not sure we need it in all cases. Even without looking at the test code, fetch then go test without even writing anything and the compiler tells you "undefined: IsLeapYear" for example. The read me says "Write a program that will take a year and report if it is a leap year." It doesn't seem too much guess that in Go you have to write a function that takes an int
and returns a bool
. Guess wrong and the compiler gives you pretty good error messages to guide you to the required API.
Also we can't ask much more from Submitting Exercises - the presented example is for Go and Leap!
from go.
This is an old issue and I'm not sure if it's intended to still be open, but I just wanted to add that the problem with having both a stub file and an example is easy to solve by using build tags.
The ledger test has that problem on steroids since it has two full implementations (a crappy one that the user has to refactor and a less crappy example). What I did there was to add at the top of the example.go file a comment line // +build example
and at the top of the exercise file (ledger.go) a comment line // +build !example
. The travis scripts run go test -tags example
so they test the example file and ignore the exercise file.
from go.
Good point. I'm not actually sure if we came to any conclusion with this. I think it could be useful to do it only for the first exercise to help first-time users / first-time Go programmers, but I actually like that most of the time it's up to the user to read the error messages and look at the test code to figure out what to do.
from go.
The first few exercises have stub files now. I think we can finally close this one.
from go.
Related Issues (20)
- Improve test output for the Clock exercise
- Enable test runner v3 UI for all concept exercises
- Ensure package names are unique
- Adding concurrency concepts to the syllabus HOT 3
- Community contributions are paused for this repo
- Outdated information in the 'Randomness' section HOT 1
- ErrStop and ErrInvalidBase not defined in the test file. HOT 1
- Booking up for Beauty: Better explanations for tasks HOT 1
- Update go version to 1.21 in go.mod across all or subset of problems? HOT 1
- Remove check for short test in benchmarks
- Hello world: Error: not in workspace HOT 1
- Building a training set of tags for go HOT 22
- Bug: instructions for kindergarten_garden do not match requirements HOT 2
- Define more test cases for resistor color HOT 1
- Expanding test cases for Vehicle Purchase exercise in the Go track HOT 1
- Need for speed exercise CanFinish tests do not validate start with distance travelled HOT 1
- Inaccurate information for the "Runes" Concept HOT 1
- First Class Functions: task 5 misleading test? HOT 4
- Duplicated link in `parallel-letter-frequency` documentation. HOT 1
- Minor correction to instruction text for animal-magic instructions.md HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go.