-
-
Notifications
You must be signed in to change notification settings - Fork 658
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
say: generate tests #885
say: generate tests #885
Conversation
Part of exercism#605. Closes exercism#837
I chose to use the ok idiom for the error reporting here. The code can be switched to using |
exercises/say/.gitignore
Outdated
@@ -0,0 +1 @@ | |||
.meta/gen |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why ignore .meta/gen here?
My feeling on it is that unless you have more information to convey than worked/didn't work you use |
habit. Checking in binaries is usually frowned on.
…On October 6, 2017 7:07:03 AM PDT, Tom Leen ***@***.***> wrote:
tleen commented on this pull request.
> @@ -0,0 +1 @@
+.meta/gen
Why ignore .meta/gen here?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#885 (review)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
Some over achiever might want to report too big or too small. I think ok is fine here
…On October 6, 2017 7:11:36 AM PDT, Tom Leen ***@***.***> wrote:
My feeling on it is that unless you have more information to convey
than worked/didn't work you use `err`, otherwise `ok`.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#885 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
Good habit! I have it too! I only noticed because it slipped by me in anagram. I'm ok with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Def remove the gitignore file so we can track gen.
Will do. Probably not today.
…On October 6, 2017 7:49:07 AM PDT, Tom Leen ***@***.***> wrote:
tleen requested changes on this pull request.
Def remove the gitignore file so we can track gen.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#885 (review)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
@tleen I don't understand your above comment because even with |
Sorry @ferhatelmas I wasn't clear. We wouldn't be adding gen anyway, as you can run the gen without building it. I'm actually ok with it getting added to a commit so we can catch that error. The local .gitignore is a nice safety, but as you said should be done as a global policy, not at the exercise level. |
@tleen Thanks for clarification. We're on the same page then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's good to go when gitignore is removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest one small change in TestSay.
t.Fatalf("FAIL: %s\nExpected error but received: %v", tc.description, actual) | ||
} | ||
} else if !ok { | ||
t.Fatalf("FAIL: %s\nDid not expect an error", tc.description) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest adding:
+ } else if actual != tc.expected {
+ t.Fatalf("FAIL: %s\nExpected: %v\nActual: %v", tc.description, tc.expected, actual)
@@ -8,7 +8,14 @@ var tens = []string{"ones", "ten", "twenty", "thirty", "forty", | |||
var scale = []string{"thousand", "million", "billion", | |||
"trillion", "quadrillion", "quintillion"} | |||
|
|||
func Say(n uint64) string { | |||
func Say(n int64) (value string, ok bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with ok bool
here. The standard library has instances like it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does anybody know if/where there is some sort of community accepted definition or guideline as for when to use an err
vs an ok
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not found a straight out "accepted definition". There is discussion. Here is one from 2015: https://groups.google.com/forum/#!topic/golang-nuts/e5qIlnhpgg0
The two points I note are:
- when only one possible error condition, a bool is fine.
- using an error is more flexible for future updates.
I think for Say, it meets no. 1 (out of range is the !ok case), and doesn't warrant no. 2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @leenipper that was sort of my take on it too. Good to see I was not alone in it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@leenipper thanks for catching that. New patch on the way soon.
The preference is for a top level one.
Part of exercism#605. Closes exercism#837
Part of exercism#605. Closes exercism#837
This brings the Go track in line with others.
Say
now returns(string, bool)
so it can indicate when a value is out of range.Part of #605.
Closes #837