When reading code, you want somthing simple and to the point most of the time (if that). Yes, it's nice to be able to tunnel down into the details - but this w

When reading code, you want somthing simple and to the point most of the time (if that). Yes, it's nice to be able to tunnel down into the details - but this was fixing a bug, the code should just have a short description and more so - the reference number of the bug and if you need to, you can look that up on your bug tracking solution and get that detail. Big problem with detailed comments, things change and comments (like code) can become obsolete/redundant and not reflect the code as the code got updated, but the ocmment did not. No solid solution really and gets down to preference and also mindfulness of the life of code/comments. Would be great to have code that you could rightclick and get the documentation, some woudl even prefer being able to write documentation and that gets turned into code, others would love code that could could be autodocumented. Get's down to taste, preferences and more so, experience. See, every programmer over time will eventually encounter a situation on somebody else's code that they are maintaining, fixing or replacing and find that the comments do not reflect the code. You eventually get down to the stage that you almost actively ignore comments based upon such experiences. So whilst a detailed description in the form of a comment is good, it can and should be elsewhere, either the initial spec and program documentation or in this instance - bug tracking software system and just simple short line with bug reference or indeed just bug reference.