-
Notifications
You must be signed in to change notification settings - Fork 47
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
Ports - Mina #24
base: master
Are you sure you want to change the base?
Ports - Mina #24
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,16 @@ | ||
# Determines if the two input arrays have the same count of elements | ||
# and the same integer values in the same exact order | ||
def array_equals(array1, array2) | ||
raise NotImplementedError | ||
if (array1 == [] && array2 == [] || array1 == nil && array2 == nil) | ||
return true | ||
elsif array1 == nil || array2 == nil || array1.length != array2.length | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not-actual-feedback industry experience note: It's not 100% necessary to use elsif and else for this particular set of logic because of the fact that you're returning early. The early return naturally excludes any logic that happens later in the function. You could argue, and I tend to lean that way, that it's better style (and more future-proof) to keep the if/elsif/else structure, just as you have it. At the same time, you may encounter (as I have at work) some IDEs or tools that enforce removing these clauses from the statements they surround when early returns exist and they're not absolutely necessary. I wouldn't change what you have, but I thought you'd appreciate knowing that some shops will consider this style "wrong" and some shops will consider this style "right". It's something you'll find out and adapt to when you get there. |
||
return false | ||
else | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not-actual-feedback industry experience note: It's not 100% necessary to use You could argue, and I tend to lean that way, that it's better style (and more future-proof) to keep the I wouldn't change what you have, but I thought you'd appreciate knowing that some shops will consider this style "wrong" and some shops will consider this style "right". It's something you'll find out and adapt to when you get there. |
||
array1.length.times do |item| | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [nit] Using the name |
||
if array2[item] != array1[item] | ||
return false | ||
end | ||
end | ||
return true | ||
end | ||
end |
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.
[nit] Technically, comparing with
[]
relies on the built-in array equality operator. It's also redundant with checking length, since if both arrays are equals to empty arrays, they will both havelength
of 0. You should be able to safely removearray1 == [] && array2 == [] ||
.