I kinda hate line comments in code, my first instinct is to ignore them entirely and if and only if I was not able to understand the code on the 2nd attempt, I’ll check the comment. From my experience they are outdated and misleading way to often to be trusted and almost always are a bad sign. For example

def calculate_something(data, options) -> int:
  # [1] adjusting the data because of ISSUE-123
  adjusted = adjust(data)
  
  # [2] removing the data because it's bad
  new_data = filter(adjusted, ...)
  new_new_data = filter(new_data)
  
  # [3] option.a and option.b don't work together, handling that
  if ('a' in options and 'b' in options or 'c' in options):
	  ...

1. Mentioning the ticket in comment is good, but – commit contains that info already.
2. From that I don’t know if the first filtering or the both of them are caused by “bad data”. I would have to guess OR take a look at the commit history, once again, why would I need comment then?
3. Was the if statement updated after the commit was written? Is it even true now? Yeah, the answer or at least a clue would be in the commit history.

My point is, documentation is very important in transferring knowledge and providing the right abstractions, but I would argue that:

• if the reason for doing something is not obvious, it should be saved as an immutable record in git history, not as a line of words that is too often forgotten;
• if the way something works needs to be described, it should be done in the function / module comment, not in the line comment. Because implementation might change, but the abstraction should stay.