3 ms·
Programming languages aren't just used to tell a computer what to do. They are languages (albeit simple ones with limited expression available). People who le
by mikekchar 9y ago
Programming languages aren't just used to tell a computer what to do. They are languages (albeit simple ones with limited expression available).
People who learn a second human language often fall back on a crutch known as "code switching". With code switching, when you don't know how to express something in the language you are learning, you switch back to your native language. This can often help people develop more fluency because they don't sit around concentrating on trying to find the correct term. They can say the parts that are difficult in their native language and then move on to the rest of the conversation.
However, code switching ultimately slows down your progress as a language learner. If you don't know how to express what you want with the correct grammar or vocabulary, it's usually better to try to find a different way to say it. By doing this you exercise your ability to be flexible in your speech. The code switcher tends to hit a ceiling very quickly and never becomes able to express themselves in the new language -- because they never have to. Finding alternate ways to express yourself is often frustrating, slow and embarrassing, but will help you in the long run.
Comments are like code switching. It's really helpful when you've written some code and you think, "I'm not sure that people will be able to understand what this means". It helps you get unstuck from your current position and to move on to the next thing, safe in the knowledge that you have expressed what you need to express.
However, you can also look at the situation differently. If you write comments, then you do not have to express yourself clearly in the programming language. It's easy to fall into the trap of thinking that it is unimportant to express yourself clearly because 1) you have comments (which are easy to write) 2) expressing yourself in code is hard 3) it will take a lot of time to learn how to do it well 4) you might fail and end up with difficult to read code.
These are all seemingly excellent reasons for writing comments, but they will also hold you back from being a better programmer IMHO. I prefer to avoid comments, using them as a technique of last resort. However, if someone says, "I don't understand your code" you have to take it pretty seriously and find a way to express yourself more clearly.
As a side note, this is one of those areas where reasonable people can differ. Of the issues that can cause conflict on a team, I find this to be one of the biggest. No matter what your personal opinion is, it's important to work as a team and do your best to please your teammates. Code is not for the writer -- it's for the reader.
- dsfyu404ed 9y agoYou are not writing code for just you. There may be times when people fresh out of college who do not speak English as their primary language may need to understand your source. There is often back-story that needs to be explained. Something as obvious as input sensitization may have a more specific meaning behind the specific implementation, for example a legacy Orcale DB client that chokes on certain special characters. A comment in a case like that can prevent you from getting woken up at 1am because a well meaning attempt to apply the same naming rules to schemas as you do to everything broke things. If someone says they "don't understand your code" then either they suck at understanding code, you suck at writing it or both. Comments are a tool to increase the speed and accuracy with which someone else can understand your code.
- btschaegg 9y agoI don't really think this goes against what mikekchar said, though. Take your own example (the legacy oracle client): The code you're using to escape those specific characters should ideally be written in such a way that its intent is obvious even to a novice reading it. For the novice, then, the question shifts from "WTF does this do?" to "why is this here?", which would be a great example what to actually write comments for: context. Imagine you're writing some very math-heavy library. Ideally, I shouldn't be a language expert to be able to see what your code does. This still doesn't help me if I don't understand the underlying math, however. Even hints like "this operation is called XY and can be used to Z" may be very helpful if someone wants to get a hold of what it does. With that, you can look up literature for this specific part.
- mikekchar 9y agoYep. I don't disagree with either of you. I was really responding to the comment that your comments should form a kind of running commentary of the code (something which I completely bought into when I was younger, but then moved away from). There are certain things you can't express with code. I don't want to suggest that you stubbornly refuse to express it at all in those cases :-). It's just that it's a technique of last resort, not a technique of first resort (if that makes any sense).