

Ah yes, one of the major questions of software development: to comment, or not to comment? This is almost as big of a question as tabs vs spaces at this point.
Personally? I don’t really care. Make the code readable to whoever needs to be able to read it. If you’re working on a team, set the standard with your team. No answer is the universally correct one, nor is any answer going to be eternally the correct one.
Regardless of whether code comments should or shouldn’t exist, I’m of the opinion that doc comments should exist for functions at the very minimum. Describe preconditions, postconditions, the expected parameters (and types if needed), etc. I hate seeing undocumented **kwargs
in a function, and I’ll almost always block a PR on my team if I see one where the valid arguments there are not blatantly obvious from context.
This depends. Many languages support 1 liner aliases, whether that’s
using
/typedef
in C++,type
in Rust, Python, and TS, etc.In other languages, it may be more difficult and not worth it, though this particular example should just use a duration type instead.