4 ms·

One big thing that has changed in regard to comments is that variables and functions can have longer names now. In most modern languages it is considered bad p

One big thing that has changed in regard to comments is that variables and functions can have longer names now. In most modern languages it is considered bad practice to have single letter variables, or even abbreviated ones, except in very well known cases. So the rule of thumb for languages like python or ruby is that if you need comments to understand what your code is doing, then you messed up somewhere. Make it easier to read, keep your functions small, and add docstrings. Save your comments for why you're doing something. But if you're using a less readable language like c, then by all means, comment everything along the way. I just read a comment I wrote a few years ago that said "I don't know why I have to do it the long way, but it's the only thing that works consistently" over a bit of seemingly verbose code that I would have tried to simplify if I didn't remind myself of that previous struggle.

Stratoscope 5y ago
In the previous century I worked at a company that offered a SQL database, and the mandatory coding standard included: - Maximum of six characters for any function name. Three characters for the category and three for the actual function. Imagine a code base where every function has a name like strcmp, strlen, etc. So you might have a name like sqlijn for an inner join. - 80 column line limit, with the first 40 columns reserved for code, and the second 40 columns for a comment. A comment was required on every line of code. So yes indeed, you might see this classic: ++i; /* increment i */ I was hired to build a Windows GUI for the database, and I explained that Windows API functions had much longer names and I was going to run out of room to do much in 40 columns. Thankfully, they gave me special dispensation to follow Windows conventions in the Windows code.
- ChrisMarshallNY 5y ago
  My function/method/property/variable names can be quite long. Most of my documentation is headerdoc-style stuff, at the opening of methods, or above properties. I generally don't have much inside methods, unless I think the code is a bit obtuse, and needs a hand. Then, it's more important for me to document "why," as opposed to "what."

Stratoscope 5y ago

In the previous century I worked at a company that offered a SQL database, and the mandatory coding standard included: - Maximum of six characters for any function name. Three characters for the category and three for the actual function. Imagine a code base where every function has a name like strcmp, strlen, etc. So you might have a name like sqlijn for an inner join. - 80 column line limit, with the first 40 columns reserved for code, and the second 40 columns for a comment. A comment was required on every line of code. So yes indeed, you might see this classic: ++i; /* increment i */ I was hired to build a Windows GUI for the database, and I explained that Windows API functions had much longer names and I was going to run out of room to do much in 40 columns. Thankfully, they gave me special dispensation to follow Windows conventions in the Windows code.

ChrisMarshallNY 5y ago
My function/method/property/variable names can be quite long. Most of my documentation is headerdoc-style stuff, at the opening of methods, or above properties. I generally don't have much inside methods, unless I think the code is a bit obtuse, and needs a hand. Then, it's more important for me to document "why," as opposed to "what."