| ▲ | yearolinuxdsktp 2 hours ago | |||||||
It’s not a myth, it’s a sound software engineering principle. Every comment is a line of code, and every line of code is a liability, and, worse, comments are a liability waiting to rot, to be missed in a refactor, and waiting to become a source of confusion. It’s an excuse to name things poorly, because “good comment.” The purpose of variables should be in their name, including units if it’s a measurement. Parameters and return values should only be documented when not obvious from the name or type—for example, if you’re returning something like a generic Pair, especially if left and right have the same type. We’d been living with decades of autocomplete, you don’t need to make variables be short to type. The problem with AI-generated code is that the myth that good code is thoroughly commented code is so pervasive, that the default output mode for generated code is to comment every darn line it generates. After all, in software education, they don’t deduct points for needless comments, and students think their code is now better w/ the comments, because they almost never teach writing good code. Usually you get kudos for extensive comments. And then you throw away your work. Computer science field is littered with math-formula-influenced space-saving one or two letter identifiers, barely with any recognizable semantic meaning. | ||||||||
| ▲ | thayne an hour ago | parent | next [-] | |||||||
No amount of good names will tell you why something was done a certain way, or just as importantly why it wasn't done a certain way. A name and signature is often not sufficient to describe what a function does, including any assumptions it makes about the inputs or guarantees it makes about the outputs. That isn't to say that it isn't necessary to have good names, but that isn't enough. You need good comments too. And if you say that all of that information should be in your names, you end up with very unwieldy names, that will bitrot even worse than comments, because instead of updating a single comment, you now have to update every usage of the variable or function. | ||||||||
| ▲ | f1shy an hour ago | parent | prev | next [-] | |||||||
>> Every comment is a line of code, and every line of code is a liability, and, worse, comments are a liability waiting to rot, This is exactly my view. Comments, while can be helpful, can also interrupt the reading of the code. Also are not verified by the compiler; curious, in the era when everyone goes crazy for rust safety, there is nothing unsafer as comments, because are completely ignored. I do bot oppose to comments. But they should be used only when needed. | ||||||||
| ▲ | crazygringo an hour ago | parent | prev [-] | |||||||
No. What you are describing is exactly the myth that needs to die. > comments are a liability waiting to rot, to be missed in a refactor, and waiting to become a source of confusion This gets endlessly repeated, but it's just defending laziness. It's your job to update comments as you update code. Indeed, they're the first thing you should update. If you're letting comments "rot", then you're a bad programmer. Full stop. I hate to be harsh, but that's the reality. People who defend no comments are just saying, "I can't be bothered to make this code easier for others to understand and use". It's egotistical and selfish. The solution for confusing comments isn't no comments -- it's good comments. Do your job. Write code that others can read and maintain. And when you update code, start with the comments. It's just professionalism, pure and simple. | ||||||||
| ||||||||