Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Are you familiar with the concept of ‘coding your documentation?’ Code often changes without the comments being updated so making the code as informative as possible has lasting benefits.

It is much easier to use descriptive variables than keep the comments up to date.

Additionally, descriptive variables allow anyone to read and more quickly understand the code.



> Are you familiar with the concept of ‘coding your documentation?’ Code often changes without the comments being updated so making the code as informative as possible has lasting benefits

Yes, and I agree 100% with it.

It is much better to write self-documenting code than comments. I just contend that descriptive variable names are not the way to self-documenting code. Of course, I'm talking about local variables whose scope should never go beyond a single screen of code. Globally accessible identifiers (e.g. functions) should of course have very long and descriptive names.

> Additionally, descriptive variables allow anyone to read and more quickly understand the code.

This does not ring true to me, but maybe it depends a lot on the context. At least in numeric mathematics, you always want to name your numbers, vectors and matrices using single letters (as they appear in the corresponding paper). Using "cute" descriptive names hinders a lot the readability of formulas.


Ah, I think the context of your programming and mine are quite different. I don’t do any mathematical formulations beyond basic manipulations.

I can see where someone writing complex mathematical formulas in C would definitely benefit from single character variable names


The "x" in mathematics is completely different to an "x" in some business logic.

Business logic tends to be concrete, not abstract. Mathematics tends to be abstract, not concrete.

Yes, using x,y,a,b,c as names in the quadratic formula makes sense.

But so does "isOverCreditLimit" and "MonthlyInsurancePremium" in business (leaving aside arguments about camelCase etc etc).

Business logic needs to reflect the intent of the business. There is rarely the case for an "x" to "solve for".

Deconstructing a mobile phone plan into code is not the same as deconstructing a math paper. Quantitative mathematics is a very different computing environment to business logic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: