we don't need to comment self explanatory code but if I got into error and found solution from somewhere I comment that to remember afterwards. But sir I don't think I comment as much as I should.
if(someoneElseWillReadMyCode) commentLots(); Normally I just use self-explanatory variable names
It's compulsory for us to write comments in source codes for extra assignment marks so yeah, I guess I do. Else, I won't even bother. One reason I can think of which seconds the idea of writing lots of comments in your code would be when you are writing a piece of code mainly for educational purposes, wherein other people would read them and understand your ways and methods. I haven't met with situations in which I needed my own hint as to what I did with codes that I wrote myself.
In my codes here, I always try to be as commenty as possible. Sometimes too much, like in the PythonEdu series :) Another thing is when I intend a surprise, like in the Hello World case. There I don't comment at all, until the riddle is solved ;)
most of the time I live by the rule: it was hard enough to write the code, so the code is documentation enough. 😈 and later when I review my own code I hate myself for that, because I have no freaking clue what I did 😭
I comment if necessary. But I never add Yoda ^^
Truly speaking, I hate to write comments but they are very handy in terms of understanding the code:)
A good and clean code should document itself. Well-named variables and methods speak about the intent of the programmer. Sometimes, however, the code is nevertheless incomprehensible and should be documented as a comment. Comment // TODO sometimes is necessary.
I comment while typing and do a final editing when i'm satisfied with my work. If I expect contributions on the code I'll try to be as verbose as possible. Commenting skills as coding skills improve with practice. I remember myself writing some comments that look useless now but at that time, helped me carving the concept in my mind til the point that I can now say: "it was a useless comment".
In the first half of my career, I worked on projects that predominantly required heavy code comments. As I transitioned to agile teams committed to TDD / BDD, general code comments became a liability, rather than an asset to code quality. Our code review process focuses on readability and test coverage of our code. If we find a comment attempting to explain something in the code, we attempt to explore whether the code could be improved to clarify what ever isolated condition that was being commented. The goal is to let the readability of our code be the source of truth rather than the comments. We can trust the code and the unit tests. However, we cannot trust the comments for several reasons. 1. Comments may not be consistently thorough for all developers and all code. 2. When code changes, comments are not guaranteed to change accordingly and may not be thorough. 3. Comments cannot be validated by the compiler or via unit tests and therefore subject to human error. 4. The context of the comment may have changed as other code has changed. This could cause even more confusion if the comment carries a different meaning in the new context. Bottom line, comments are not reliable, cannot be tested or validated, and is often redundant to what can be inferred by well written, readable code.
i often write comments to plan out code before I write it. I don't think typing is what takes up Development time - its thinking, planning, problem solving, reading documentation (of libraries or bits of bits of the language I don't use often)
I always comment. It's really useful if other people are going to see your code and also useful when you return to your code months or years later so that you can remember what everything does without having to work it all out again. It's a good habit to get into if you're going to code as a job because quite often you'll be coding and passing it on to other people to use and maintain.
Comments explaining the purpose of a method must always be there in a code, it makes much easier to understand when the code is being reviewed...
/* I comment were I thnk its necessary to comment otherwise I don't*/
Mostly little inline phrases for complicated/deep methods I may want to later modify/study; However I see how others use the ' //TODO: ' at the head of their comments; it is supported via third-party plugins— but that's a choice+
I add some comments to my HTML and CSS for sorting my elements and to help me find what i need to see and/or edit faster 🏃👍
sometimes, it helps to read and understand the code wich was written long ago
On important projects, all the time. I have a set of standards that I have set that I follow for important projects. Personal projects, or things that take me under 5 minutes to do, comments I don't do, as I feel like they waste my time. Perhaps a selfish thought but it is how the world wants us to work: fast, efficient, low cost.