How many comments?

[hanst99]

On topic: It's not a matter of quantity, but of quality. In many places commenting would actually decrease readability and distract from the actual code. If you're relying on some on some specific protocol ( like left < param < right, something along those lines) you should mention that somewhere - but if it gets too long, put it in a separate documentation. If half your code consists of comments, you'll probably end up folding them all away and never looking at them again anyways.

[rapidcoder]

An iterator is a "thing", and a vector iterator is what type of "thing" it is (or could be)

Mathematically both are types, albeit an iterator is a higher kinded type parameterized by the type of the object it iterates on. Type is fully defined by the operations that are allowed on the object, and saying something is "iterator" already says something about the allowed operations - so it is a type.

[Cubbi]

rapidcoder wrote:

Type is fully defined by the operations that are allowed on the object,

Wrong, C++ has a nominal type system: struct A{}; and struct B{}; are different types.
However, type classes (such as the iterator categories) in C++ are indeed pure structural (defined entirely by the allowed operations)

[rapidcoder]

Ok, right, agreed.

[Zephilinox]

most of the time I don't use any, then a week goes by and it takes me an hour to understand my code, I should use them more often and I when I remember to do so its a lot easier, but sometimes I'm just working on a project which I expect to end in a couple of days, then expand it and it goes on for a couple more, you know how it is :3

[BHX]

My projects don't ever get that complex. I can code something and a month or more later come back and know exactly what I was doing.

[Ikaron]

@rapidcoder
This has long since diverged from the original point you tried to make regarding templates and type strictness, which I was responding to. A case where an argument must be an iterator is completely irrelevant to templates as it is a case not unique to templates. The only thing you can restrict which is unique to a template is the allowed template types, to which I was responding that if you're doing this you probably shouldn't be using a template.

[ThangDo]

My projects don't ever get that complex. I can code something and a month or more later come back and know exactly what I was doing.

@BHXSpecter: its either you have an extreme consistency in your code writing skills or you have a spectacular memory

I prefer to have mostly one-line comments in my code and try to be as consistent as possible, so that when I look at it, I know which is which and what doing what.

But still, comments are important. Its for the best interest of maintenance and readability. I would freak out if I see any code without any comments.

[chrisname]

Comments should be terse but informative. They should never explain how something is done (that should be self-evident), only what you're doing or why you choose that method.

As for personal style, I put comments at the top of each function, structure, class, enum, etc. in both the source and header file (though I might stop putting them in the source files since they aren't really needed there) describing the object in a single sentence, with a sentence for each parameter and the return value (for functions). I use terser comments for static stuff (for a static function I won't describe the variables or the return value; I just write a single sentence stating what it does). I don't comment local variables, but I comment global variables (if I use them) and I comment structure and class members with a short sentence. If a function performs things in a few steps, then I'll either put one comment for each step (if each step is a few lines by itself) or put a single comment before each of the steps (if each step is a one or two lines, like a function call).

I'm extremely consistent in projects, but I change my style slightly from time to time. Any code that I've written in the last year or two would look more-or-less the same.