I know I’m probably doing it wrong but this is how I feel whenever I write unit tests
Asking as a newbie programmer: how do you suggest we write comments that explain the 'why' part of the code? I understand writing comments explaining the 'what' part makes them redundant, but I feel like writing it the former way isn't adding much help either. I mean, if I created code for a clock, is writing "It helps tell what time it is" better than writing "It is a clock" ?
It would really help if someone could give a code snippet that clearly demonstrates how commenting the 'correct' way is clearly better than the way we are used to.
Made a comment
basically how it feel when a professor requires u comment every single line of code u write to explain it. I know people tend to drop out of real engineering to do programing but an entire 4 years of this bullshit as opposed to just a couple classes sounds way worse than calc 3 or differential equations.
I know some folks are joking about and dunking on this, but in modern times, I have justification. Call me lazy, but I have found myself writing out these comments and then letting the AI take over to at least give me a sketch of an implementation. Works reasonably well and saves me a lot of time and effort. Mostly I don't bother to remove them, though I usually edit them a bit.
On the other hand, there are factions within my colleagues who steadfastly insist that commenting is unnecessary and to some degree even potentially harmful, and that if you feel the need to comment your code, it means your code should be improved so that it's obvious what it is doing without the need for comments.
We have to go deeper.
Will each level of smaller clocks get one additional hour?
someone else's code would have the wrong values.
// Open file fopen();It should have the numbers change in the middle like a digital clock but look like the numbers on a clock.
When you ask a Dev to test their own code
@Vordimous Wait for daylight saving time...
@Vordimous @linuxgal when I see this sort of thing when reviewing PRs, I write words to the effect of "tell me WHY it's doing that, not WHAT it's doing". The "what" is usually obvious from the code and thus not worthy of comment. The "why" will enlighten your colleagues (and future you).
Commenting code is a super important habit to get into—it not only helps others understand your thought process but also makes it easier for you to pick up where you left off if you revisit the code later. Plus, well-commented code can significantly reduce the onboarding time for new developers on a project. Remember, comments should explain the "why" behind the code, not just the "what." For instance, stating why you chose a particular algorithm or data structure can be far more helpful than just labeling it. According to a study by SmartBear, 44% of developers regard poorly documented code as a top cause of project delays, so it’s definitely worth the extra effort!
