Some things I’ve noticed and other pointers. Some of these are repeating in other places too. Keep in mind that these should be approached just as what they are - tips, pointers, suggestions what can be looked at and possibly improved. They may give you some other ideas what can be improved further along the way. Remember also to do small changes at a time and check often if everything is working properly after them.
time,meridian = starttime.split()
time
is name of the build-in module. It’s best to avoid using names that are shadowing names build-in modules or functions. However if such name really would be the best, then underscore can be added at the end of it, like time_
, to kind of still keep the name and don’t overwrite build-in module name.
startminutes_hours = ''.join('{:.2f}').format(int(minutes) / 60)
starttime_hours = float(startminutes_hours) + int(hours)
I’m not entirely sure what is supposed to be happening here, but it kind of looks that float
number is converted to str
just to be converted back to float
in the next line. Is this just an unconventional way to round number? Why not use round
function when minutes are divided, with optional argument specifying number of digits precision for it? startminutes_hours
isn’t used anywhere where it might need to be str
. It’s not used anywhere else actually, so one step further might be removing that line and move minutes division and rounding it to the following line.
- Repeated type conversions
int(minutes)
, int(hours)
, int(totaltime_hours)
, str(totaltime_minutes)
, etc. - try to minimize number of places where type needs conversion. Taking as example minutes
and hours
, there’s no reason to keep them as str
when defined and then converting to int
whenever they are needed, just convert them to int
when being defined and use that later.
if dayoftheweek is not None:
elif dayoftheweek is None and number_of_days == 1:
elif dayoftheweek is None and number_of_days > 1:
else:
Notice that in here if first condition catches dayoftheweek is not None
, then in other possible cases dayoftheweek
have to be None
and such condition can be safely removed from elifs leaving there only condition for number_of_days
.
- Staying in this part of the code, take a look at what is happening with
new_time
.
new_time = str(total_hour_12format) + ':' + str(totaltime_minutes)+ ' '+ str(meridian_l[0]) + ', ' + days_in_week[day_index % 7] + ' (' + str(number_of_days) + ' days later)'
new_time = str(total_hour_12format) + ':' + str(totaltime_minutes)+ ' '+ str(meridian_l[0]) + ', ' + (days_in_week[day_index % 7]) + ' (next day)'
new_time = str(total_hour_12format) + ':' + str(totaltime_minutes)+ ' '+ str(meridian_l[0]) + ', ' + days_in_week[day_index % 7]
new_time = str(total_hour_12format) + ':' + str(totaltime_minutes)+ ' '+ str(meridian_l[0]) + ' (next day)'
new_time = str(total_hour_12format) + ':' + str(totaltime_minutes)+ ' '+ str(meridian_l[0]) + ' (' + str(number_of_days) + ' days later)'
new_time = str(total_hour_12format) + ':' + str(totaltime_minutes)+ ' '+ str(meridian_l[0])
Notice that part of the assignment is always the same, this part can be placed before of the conditional block, with adding just the changing part in the conditional block (or in two blocks).
elif int(totaltime_hours) >= 12 and int(totaltime_hours) < 24:
Python have a nice way to chain and simplify such conditions referring to the same variable, i.e. a >= 1 and a < 3
can be written as: 1 <= a < 3
They are often saying exactly what is happening in the code. That’s usually clear after reading the code and not really needed. What would be better is to include in comments the reason why something is happening. Taking for example:
while int(totaltime_hours) >= 24: # If the totaltimehours is greater then 24 then subtract by 24
totaltime_hours = int(totaltime_hours) - 24
Comment here is just repeating the code as such it’s not needed and could be removed. If instead comment would say why it’s looping and subtracting from totaltime_hours
, that would make comment beneficial for understanding the code.
Take a look at PEP 8 style guide for python, especially regarding way of naming variables and maximum length of line. It defines some good practices to keep code readable and consistent with how usually others format code written in python.