Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualKhaiy

Posted 23 July 2013 - 06:26 PM


I never said it should be a rule. Just my opinion. I don't like it when i have variables that are only used once just for the sake of knowing what they are used for. That's what comments are for. If i use them more than once i almost always use variables for them because it's easier to change the value of it. I only have to change one value and not find and replace 3 values. But if the value is only used once in the whole program why not just write it in there and make a small comment. I know it's preference but still i don't like it when there are 'unnecessary' variables.

 

As I said, there are bound to be cases where your preference here is the best choice. But in practical terms, as I also said, declaring a variable with a good name takes no more time than writing a comment, and a well-named variable should be equally clear about its purpose as well as more concise and more convenient for code maintenance.

It will normally be true that a number, used only once and only in a function's local scope, can be similarly well represented by a plain integer/float/double/whatever or a named variable. But it is less convenient and less natural for a programmer to refer to a comment, located outside of the code fragment being reviewed, to figure out the significance of a variable which is being used when a descriptive variable name can document its own purpose and significance in-place.

There are other design issues related to this, described quite well in the book I mentioned above. The shortest summary is that named variables help a programmer manage the complexity of the project, while magic numbers do not. A magic number is improved by a descriptive comment, but is still inferior to a named variable. But my main point is that your preferred approach on this offers no advantages over a named variable, not even saving time, while being less clear, less concise, and less expandable.

I would suggest that you think a bit more broadly about both approaches when comparing them. Just because you aren't using named variables in these cases doesn't mean that they are useless, and aside from satisfying your pre-existing preference your style isn't even providing the one benefit you attributed to it. I would be interested to hear any other arguments you have, but at the moment I am entirely unpersuaded.

 

EDIT: Added quote to make the response clearer.


#1Khaiy

Posted 23 July 2013 - 02:25 PM

As I said, there are bound to be cases where your preference here is the best choice. But in practical terms, as I also said, declaring a variable with a good name takes no more time than writing a comment, and a well-named variable should be equally clear about its purpose as well as more concise and more convenient for code maintenance.

It will normally be true that a number, used only once and only in a function's local scope, can be similarly well represented by a plain integer/float/double/whatever or a named variable. But it is less convenient and less natural for a programmer to refer to a comment, located outside of the code fragment being reviewed, to figure out the significance of a variable which is being used when a descriptive variable name can document its own purpose and significance in-place.

There are other design issues related to this, described quite well in the book I mentioned above. The shortest summary is that named variables help a programmer manage the complexity of the project, while magic numbers do not. A magic number is improved by a descriptive comment, but is still inferior to a named variable. But my main point is that your preferred approach on this offers no advantages over a named variable, not even saving time, while being less clear, less concise, and less expandable.

I would suggest that you think a bit more broadly about both approaches when comparing them. Just because you aren't using named variables in these cases doesn't mean that they are useless, and aside from satisfying your pre-existing preference your style isn't even providing the one benefit you attributed to it. I would be interested to hear any other arguments you have, but at the moment I am entirely unpersuaded.

PARTNERS