[Tkinter] Dynamic checkbox treeview issue

[OogieM]

maybe this was a code comment instead of a method comment. But there should be a comment that describes what the method does. Comments describing blocks of code inside a function/method should be fairly rare.

I generally start any code by writing a comment that is the pseudo code of what I am trying to accomplish and in some cases why or other notes from my specification that I need handy for me to work with. Making those things single line comments is a single keystroke, I'll investigate making a shortcut to make them docstrings instead. Generally once the code is "done" I go back and either delete or clean upthose comments and remove excess print statements. As I'm getting more proficient with the debugger I am using far fewer print statements but some of the early stuff still has a lot of them in it.

I am not sure if "# Set up to build the database query.." is describing the entire method, or if it is describing what is going on in the if statements that follow.

Just the statements that follow.

Thanks for the code suggestions. I am the primary programmer on what is a huge project. My most recent coding has been Android Java for the mobile app that is the companion to the Python app. The mobile app is used to collect field data chute side with the animals including printing identification labels with bar codes for all tissue samples that link back to the official federal ID of the animal. The Python app is the desktop that creates the required official laboratory submission forms for those tissue samples. The users are veterinarians. I'm a farmer first and a coder second. (Retired from high tech but that was 20+years ago) and trying to learn Python as fast as possible to get this project done. The only other person working on the project is my husband who does all the low level driver code on the mobile app to handle the various hardware we have to support and some Java coding. I'm the only one doing naytign in Python.

---

You may have noticed that I don't like using type identifiers in variable names. I don't care that you are using a list to store display names. I'm fine with a tuple or really anything that I can index and iterate. The "display names" part is important. The type of container holding the display names is not. If it is not important and does nothing to aid understanding, it does not belong in the variable name.

Circling back to this to explain why I won't be taking that advice.

In my system I have many cases where variable names are similar because they are in general working with similar data. So I like knowing that this is the list of display names not that this is a single display name nor is it a cursor of display names etc. I also try to keep variable names consistent across both the Python desktop app and the Java Mobile app so I don't exactly follow either system's conventions for naming. I find that for me, that makes it less likely that I will make stupid programming errors by confusing variables.

Some of the simpler code things you mention are being implemented now. The cmd += for example.

I also dislike (mild dislike) "get". I want to know the selected column names. I don't really care that I have to "get" them

This I am considering implementing. Only issue is that I have a very large set of code where consistent naming includes getting the item(s) in question so that system of including the verb for what I do with the item is sprinkled all over everywhere. To change it in one place and not another seems wrong to me and I'm not sure whether to go through the effort of changing them all now.

To explore that I'm looking at the refactoring tools in PyCharm to see if I can do it easily that way. I've been a bit leary of using some of those automatic renaming/refactoring options mostly because I've seen things get messed up by partial strings being refactored incorrectly. It's been a while (a number of years) but the scars from trying to recover are still with me.

The comments as does make sense but my muscle memory is of always making single line comments. I haven't been particularly successful in changing that but I may go back and convert them later. As I said I do a comment block initialy to get me started with coding.

Thanks again for all the suggestions

PS

I just realized that part of why I do display_first_name and not selected_first_name (as an example) is because I will be further selecting from the treeview shown to do more things. The search is to get the group down to a smaller set that I will then further select from by selecting individual records. SO in my mind I am not selecting first names I'm displaying them and select is another level down. Hard to explain but as I was trying ti implement your ideas I was fightinh it and when I went back to the specification I see the clear dsplay this and then selct from that structure so the naming makes more sense with that in mind.