Coming from a non-Apple embedded programming background, I've noticed that in the Apple dev world it appears more acceptable to omit comments that explain what you're doing in your code. Although there are always coders around who are lazy about commenting, in the fields that I've worked in, professional code was usually well-commented and every job required good comments. But in the Apple world it seems like it's considered a little more acceptable, because I've found code from Apple and major vendors and many other places that is poorly commented, and some iPhone devs I've worked with don't comment, and they argue that there just isn't time to do it while meeting deadlines and therefore it's not a requirement.
Is the philosophy of omitting comments partly just that the code should be readable and that variable/function names should be chosen such that comments aren't needed? I've tried this, but for me personally it never works as well as including good comments. Maybe I'm just bad at reading code.
Or I'm wrong, and it's just that I've worked at places and in fields where they happen to comment a lot, and/or I happen to have been exposed to some atypical Apple code and devs who comment less than normal.
Location: Somewhere the streets are on fire, the sewers are flooded, and the cats are high on catnip
Posts: 529
Personally I do comments, but not on a very large scale. I'm mostly solo, so unless I'm doing work for another company or I'm in a group, I'll only put very simple comments if I think I'll have to go back later.
Also I find the language to be much easier to read than others I've worked with.
Also I find the language to be much easier to read than others I've worked with.
+1 To that.
I don't comment code as I have never needed to. If I come across a problem in the code, usually I will just comment what is going on, and return to it later on.