Rate my todo list manager's source code.

[MFG38]

I know I haven't talked a whole lot about my coding misadventures here, but suffice it to say that I've accumulated a fair bit of experience since getting into it with Python back in 2019. That said, I wasn't particularly new to coding even then, on account of my 8 years' worth of experience with ACS and DECORATE at that point. But one day that year, the "actual" programming bug happened to bite me and I started learning Python. Since then, the "real" coding I've done has mostly consisted of fairly simple, single-file coding experiments with varying degrees of usefulness... until about a week ago.

 

A few weeks ago, I started at a workshop thingamajig where I essentially get to practice my coding skills 25 hours a week. Under the tuition of said workshop, I started putting together my first non-Doom-related coding project last week - a todo list manager that runs in the command line, written in the aforementioned language. It goes by the name Colette, and it's now at a stage where the majority of the planned core functionality is implemented and working. As of today, you can print the todo list, add, remove and edit entries, and the program is also able to write and read the todo list to/from a file.

 

To that end, I was inspired to share the Colette source code in its current state, mostly in hopes of receiving some comments from the more experienced programmers here, of which I know there are a few, about how it looks. Feel free to play around with it as well if you're so inclined - just download the source code and run main.py from the src/ directory with the latest version of Python. (Some older versions may be able to run it but have been untested, 3.10 is the bare minimum to my knowledge.)

 

With that, here's a link to the project's GitHub repo:

https://github.com/MFG38/colette

 

List of currently implemented and working commands:

• add: Adds an entry to the todo list. Due dates aren't checked in any way yet, so they can be anything for the time being. I'll probably tackle implementing the parser for those next.
• edit: Edits an entry in the todo list.
• exit: Writes changes to the todo list and quits Colette.
• help: Prints usage instructions.
• list: Prints the todo list.
• rem[ove]: Removes an entry from the list by its index.
• ver[sion]: Prints Colette's version information.

 

See ROADMAP.md for a checklist of features I hope to implement, some of which may or may not actually become a reality.

 

Thanks in advance. c:

[boris]

Code looks fine to me. The only thing I noticed at a not-so-thorough glance was how you're checking the bounds of the list index. For example in CommandHandler.remove_entry_by_index you have

 

if index not in range(0, len(th.todo)):

 

That of course works, but there are no holes in the list, so you could just do something like

 

if not 0 <= index < len(th.todo):

 

Some other things I noticed:

• the task list starts at index 0, not 1
• comments above methods, consider unsing docstrings below the method header instead
• check user input for strings with just blanks
• try adding a description with a comma in the text, then exit and load again (protip: use the csv module to load/save CSV data)
• check out the plethora of table formatting modules, could make your task list more flexible

Ideas:

• make it possible (with Ctrl-C or whatever) to abort the current input
• make it recognize partial commands, i.e. not just "remove" and "rem", but also "r", "re" etc. for all commands
• make errors more visible, for example by printing them in red

[MFG38]

5 minutes ago, boris said:

try adding a description with a comma in the text, then exit and load again (protip: use the csv module to load/save CSV data)

 

It took me a while to process what you meant by this, but now that it hit me, I'm shocked it never occurred to me to test that. I'll definitely look into a solution ASAP. Thanks for the csv module pointer as well!

 

12 minutes ago, boris said:

the task list starts at index 0, not 1

 

It's mostly that way at the moment because I'm so used to 0-based array indexing and I don't want to risk breaking stuff by messing with it. But if I come up with a way to make the indexing 1-based that doesn't involve a "dummy" entry, I'll very likely implement it.

 

9 minutes ago, boris said:

Ideas:

• make it possible (with Ctrl-C or whatever) to abort the current input
• make it recognize partial commands, i.e. not just "remove" and "rem", but also "r", "re" etc. for all commands
• make errors more visible, for example by printing them in red

 

I like these, will consider implementing.

 

Your feedback is appreciated!