6 ms·
This point gets brought up a lot, but I'm not going to complain at all. In fact, just 5-6 months ago I used to be one of those programmers who would do # g
by RegEx 14y ago
This point gets brought up a lot, but I'm not going to complain at all. In fact, just 5-6 months ago I used to be one of those programmers who would do
# gets the xml
def get_xml():
It took comments like this to help me realize just how silly the whole thing was. Now I write as much self-documenting code as I can, but comment as needed.
- bonch 14y agoIt's all subjective, but that comment could be expanded to, for example, explain where the XML is assumed to be coming from or what kind of XML is expected. If the code makes no assumptions about those things, that is also something to write a comment about.
- Funnnny 14y agoSure. Comment should be "why I did this", and code should be "how I did this", some people just write in "what did I do" and walk away thought they have comment Code took from a project I'm working with: #End of package
- StavrosK 14y agoI generally become aware that I should leave a comment whenever I write something that is less than trivial (but exactly less than trivial) to write/understand. Longish list comprehension? Summarize what it does. Nested function calls? Summarize why. Etc.
- chii 14y ago> Comment should be "why I did this", and code should be "how I did this" the problem starts when the 'why' doesn't match the 'how'...which one is "correct"?