I'm always happy to point people to Code Complete (2nd ed.). It's got lots of great language-agnostic information and is easy to use as a reference. But as others have said, it's only through experience that you improve at coding.

+ rep for you, I was about to recommend that same book. It really is "the" book about how write quality code. Just a short 960 pages of line after line great advice. I took notes while reading this book, the notes were on a large white board I keep on the wall by my computer, they've been there for a year, I know them by heart now but I can't bring myself to erase them.

here is a little tip i just caught myself in - don't use random numbers in your code - give the number a variable name somewhere..

i just found a line in my code that said if ( pos.x * 1.27f <= 23.45f )

this took me like an hour to figure out why i wrote that

Or you could save some time and just write in a comment on the same line what the numbers are about. Then you don't have useless variables that could get you confused.

here is a little tip i just caught myself in - don't use random numbers in your code - give the number a variable name somewhere..

i just found a line in my code that said if ( pos.x * 1.27f <= 23.45f )

this took me like an hour to figure out why i wrote that

Or you could save some time and just write in a comment on the same line what the numbers are about. Then you don't have useless variables that could get you confused.

It takes no more time to declare a well-named variable than it does to write in a comment explaining a number, and a well-named variable shouldn't be confusing. Using magic numbers is a terrible habit. I'm sure there are situations where the approach you describe is appropriate, but advocating it as a rule sounds to me like saying that doing cocaine is fine as long as you go jogging afterwards because jogging is healthy, right? It's focusing on the wrong end of the problem.

here is a little tip i just caught myself in - don't use random numbers in your code - give the number a variable name somewhere..

i just found a line in my code that said if ( pos.x * 1.27f <= 23.45f )

this took me like an hour to figure out why i wrote that

Or you could save some time and just write in a comment on the same line what the numbers are about. Then you don't have useless variables that could get you confused.

It takes no more time to declare a well-named variable than it does to write in a comment explaining a number, and a well-named variable shouldn't be confusing. Using magic numbers is a terrible habit. I'm sure there are situations where the approach you describe is appropriate, but advocating it as a rule sounds to me like saying that doing cocaine is fine as long as you go jogging afterwards because jogging is healthy, right? It's focusing on the wrong end of the problem.

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.

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.