conventional spelling
def EggDrop(floor):
When writing an English sentence,
yore bedder aff riting korrekt ledders
than surprising the reader with non-standard spellings.
Will the reader understand the meaning? Yes.
But you could do a better job of conveying what you want understood.
Here, you and pep-8
are telling me that this is SomeClass
,
which is a bit jarring coming on the heels of def
which introduces some_function
.
Worse, down below the EggDrop(i)
call appears to be
invoking a class constructor and discarding the resulting class instance.
In a small program the Gentle Reader will remember these odd aspects
and eventually realize it's a function call.
But in a program with many classes and functions written by diverse authors,
things can quickly grow unmanageable.
Please write python code the way the rest of the python community does
when you wish to collaborate with others.
return values
The biggest critique of this code is we evaluate a complex loop
for side effects (for print
ing a result) rather than returning a result.
This makes it harder to read, since it's only way down in the middle + 1 > floor
clause that we get to the punch line which reveals the function's purpose.
Consider adopting any one of these signatures:
def egg_drop(target_floor: int) -> int:
def egg_drop(target_floor: int) -> tuple[int, int]:
def egg_drop(target_floor: int) -> str:
The middle one would return (middle, eggs)
,
while the last would return the same formatted string you're printing now.
All of them would be
unit testable,
with the first two being especially convenient to test.
(Yes, the OP code could be tested by redirecting sys.stdout
to a buffer,
but there's no need to design a Public API that is gratuitously hard to test.
In general, side effects complicate things and make testing harder.)
The "problem setup" comments at top of source file
were very nice and I thank you for them.
write """docstrings"""
I suggested renaming your formal parameter to something like target_floor
,
the floor number we binary search for,
because I found the current signature initially misleading.
I thought I understood your meaning, of "floor we took the
elevator to and performed a drop experiment from", and soon
found that interpretation was dead wrong.
Putting a """docstring""" below the signature gives you an opportunity
to describe the meaning of outputs and inputs, even if you
retain the floor
name.
Always take the opportunity to write at least one sentence,
since the signature usually won't spell out everything of interest.
Optionally go on with more description if you feel there's more to say.
invariants
There are some important relationships among your loop variables.
Write them down in # comments
.
Clearly each time we enter the while
, middle
will
be in the range lower
.. upper
.
You could have made that more clear by using a single
assignment after the while
, rather than a pair of assignments.
The intent is that upper > lower
, which is a little tricky to prove.
It is OK to have middle == lower
, and it wouldn't
hurt to mention that in a comment.
We intend that target_floor
shall be in the range lower
.. upper
,
but we neglected to check that upon function entry.
European floors would be numbered 0
.. 101
, while
American floor numbers range from 1
.. 102
.
Computer scientists like zero-origin, even if they don't live in Europe.
It would be helpful to spell out what floor numbers mean in this context,
to avoid an OBOB.
Then write the occasional unit test to verify.