3 ms·
Um. You're right that code doesn't compile itself, though. That's the job of the computer operator, who takes the code I write in my notebook and flips the cor
by krig 12y ago
Um.
You're right that code doesn't compile itself, though. That's the job of the computer operator, who takes the code I write in my notebook and flips the corresponding switches on the computer. If the computer operator isn't doing their job, they probably shouldn't be working on a project with other people.
People are fallible. People make mistakes. People get bored. That's why we write tools to do our work for us. The way we avoid making mistakes is by making the mistakes impossible in the first place. This is why typing exists, because without static type checking, people will mix up their types. Yes, it's the job of the programmer to keep their types straight. The compiler doesn't care about types. So what? The whole point of tools is to make the life of the programmer easier, not by magically transforming them into perfect programmers who never make mistakes, but to have tools that avoid, check, verify and catch those mistakes.
Comments circumvent any such tools. Suddenly, you are back to banging rocks together.
- timr 12y agoAh yes...the "humans make mistakes, so therefore we should completely ignore all concessions to the people who maintain the system" argument. Those pesky humans will be much less problematic if they can't communicate in their imprecise meatspeak.
- krig 12y agoI don't think you understand what I'm saying. The people who maintain the system are not helped by incorrect information. The information describing how the code works in comments is invariably incorrect. None of the tools we usually employ (unit tests, regression tests, compilation, etc.) apply to the comments, and describing the HOW of code in comments breaks the DRY rule unless the comments ARE the code. Now, as I said, sometimes you need to describe intent. Most of the time, that is better done through liberal use of functions, purpose-specific types and function names. For example: In C, there are multiple types of integers defined that all reduce to roughly the same types: size_t, ptrdiff_t, etc. Does the compiler care if the type is unsigned int or size_t? No. Apart from the portability reason for using these types, the other is to describe intent. A variable of the type size_t should store a size. Now, we could make the variable an unsigned int, and in a comment say that "this variable stores a size". But will this comment stay in sync with the code, when the variable later changes to a ptrdiff_t because it is now used to compare pointers? No. The comment won't get changed, because humans are fallible, and changing the comment would require making the same change in two places, one of which is ignored by the toolchain.
- timr 12y agoYeah, I got it. Machines can't verify the documentation that humans write. It's not a subtle point. Now, if the code were good enough to substitute for human-written documentation, you'd actually be addressing my argument. The people who argue that code is self-documenting tend to produce only badly documented code. The way that comments stay in sync with code is that the developer keeps the comments up to date. It isn't that hard.
- krig 12y agoDocumentation is something completely different from comments. Documentation is something you write for the interfaces you expose. This, I have absolutely no problem with. Interfaces are meant to be stable, they should be well defined, they should have human-friendly instructions and examples on use. Comments in code? That's something completely different.