it writes to the wrong filename. That's quite not 100% accurate, as the original excersice (without the bonus) tells: "Then put them into a random order and save the output into a text file." .. as you can see, no file specified.
Ahh, yes, this is fair. The filename was part of the "bonus challenge", which hopefully no one actually did :P
attr_reader vs attr_accessor.. I have always liked the idea to have inmutable objects rather than allowing a change outside of the Object itself. It doesn't feel right. So, unless there's an explicit need to change the object and do recalculation, I'd stick with attr_reader
Yeah, I'm wary of mutability, too (hence moving the arg from process to initialize). The purpose for the accessor here is so that when we initialize it, we can do self.var = ... rather than @var = ..., which I prefer because if the names become misaligned, then it will error where we try to set it, rather than where we do something after accessing it (or worse, if it doesn't error at that point, b/c nil is a valid value, and instead it blows up elsewhere in the program, or we just get really unexpected results). If we were calling the setter more than once, I'd advocate using a local var instead of an instance var. I guess I'm thinking of it as a "one-time-use" setter.
You know, the more I write Ruby, the more I contemplate making my own attr_* methods :P In this case, the way I use it, a better definition would be something like this.
One thing I could eventually do better, is follow Ruby style guide github.com/bbatsov/ruby-style-guide like single line method definitions, or somethimes using parenthesis and some other times not.
I had no issue with any of your syntactic choices (other than the -1 having mismatched whitespace). Looking at mine, there were a few weird ones, I think that's b/c I was inlining things so that my code samples in the comments would be inline, because the markdown processor doesn't seem to nest code blocks inside of lists. But, I initially wrote all my methods as multiline, and it was really just an error from trying to juggle the formatting requirements of the different places the data existed (my editor, the gist, within the comments).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ahh, yes, this is fair. The filename was part of the "bonus challenge", which hopefully no one actually did :P
Yeah, I'm wary of mutability, too (hence moving the arg from
processtoinitialize). The purpose for theaccessorhere is so that when we initialize it, we can doself.var = ...rather than@var = ..., which I prefer because if the names become misaligned, then it will error where we try to set it, rather than where we do something after accessing it (or worse, if it doesn't error at that point, b/cnilis a valid value, and instead it blows up elsewhere in the program, or we just get really unexpected results). If we were calling the setter more than once, I'd advocate using a local var instead of an instance var. I guess I'm thinking of it as a "one-time-use" setter.You know, the more I write Ruby, the more I contemplate making my own
attr_*methods :P In this case, the way I use it, a better definition would be something like this.I had no issue with any of your syntactic choices (other than the
-1having mismatched whitespace). Looking at mine, there were a few weird ones, I think that's b/c I was inlining things so that my code samples in the comments would be inline, because the markdown processor doesn't seem to nest code blocks inside of lists. But, I initially wrote all my methods as multiline, and it was really just an error from trying to juggle the formatting requirements of the different places the data existed (my editor, the gist, within the comments).