It seems this was mainly directed at me due to the quotes/paraphrasing, so I'll reply in some detail.

Hopefully the forum formatting won't destroy this too badly.

---

EDIT: I see now that some of this wasn't directed at me. I'll leave the post as-is, since trying to edit the quotes more is a recipe for disaster.

---

I've taken the liberty of reordering your quotes a bit (marked with ... in the cases there's been other text between the quotes inside a single quote block).

notice that i posted my opinion instead of rating your post down. the mistake so many people make that is the REASON I POST OPINION CONTRARY TO POPULAR is that many people seem to feel that there is only ONE envaluation in productivity, the "apparent commercial standard".

YES it is necessary to standardise when working on a team, but this is not everyone's objective. if someone wants to get hired straight out of school, then kowtow.

if on the other hand someone engages in a rich and varied set of activities during their adult/professional life, more "localised" methods are more appropriate, with a lower need for standardisation and readability.

...

if i'm writing a game, it's likely to be under 2000 lines total. for the scope of such a project, there is absolutely no need for it.

I didn't rate your post negatively. I don't think I've ever rated one of your posts negatively, even if I've disagreed with points you've made earlier.

Opinions contrary to the popular one are (of course) both valid and valuable. However, when going against the grain I would personally appreciate some reasons as to why -- especially when recommending it to someone looking for best practices and advice.

In your case, I see the following reasons for why you advocate using single-character (or up to 2-3 in larger programs) variable names:

1. Less typing.

2. You generally work on your code alone, not in larger groups.

3.Your games are usually within a scope where you don't feel the non-descriptive variable names hinder you.

4. It's what you're used to.

For 1, I presented a counter-point -- modern tools help alleviate this (making it nearly moot), while still offering the benefits of more descriptive variable names.

For 2, you seem to acknowledge that if you were to work in larger teams would mean a shift in coding style/conventions. Again, personally, I would consider best practices to strive for something more universally understood when the cost of doing it is comparatively cheap (due to my point against 1).

For 3, I would still maintain that more descriptive variable names would offer a quicker at-a-glance understanding of any chosen piece of code snippet. Basically, I don't see how more descriptive variable names could ever be of non-negative value. Again, given the 'cost' of making the variables names more descriptive (partly due to my counter-point for 1), I consider this a non-argument.

For 4, I don't find that a compelling argument for why beginners should do the same. It might be a reason for why you don't want to change it, but that's not something a beginner can relate to.

I've never insinuated that you're lacking skill or experience, or that you are a bad programmer.

The reason why I found it ironic was not because of what you assume in your post, but because I consider typing to be typing. You seemed to want to type as little as possible when you code, but you seem to not care how much you type in other cases. Paradoxical might have been a better word.

and, so you know, i don't have time to type out superfluous appellations,but i have all the time in the world to explain myself and encourage you to be less depreciative toward others. i am not bad, nor am i new. it's that simple.

This is where I disagree with you the most.

If someone asks for best practices and advice, and someone else posts their opinions, they should be prepared to have those opinions challenged.

If someone said they wrote all code on a single line, without any line breaks, I would question why and propose other ways of doing it. Ways I found superior.

That doesn't mean I'm attacking the poster, but it does mean that I don't find that style good advice.

Whether you want to engage in discussion or attempt to shut it down without any further replies is up to you.

That does not, however, mean that others shouldn't be allowed to ask or challenge what you've written, which is the vibe I'm getting from this quoted text.

Have you considered that some of your negative replies/votes might be caused by your way of writing more-so than your post content?

i am not bad, nor am i new.

and, i do not use long variable names.

and that is really all that needs to be said, or considered.

Nope. One more thing needs to be said. I'm sorry I called you a bad programmer. :/ It's not a good practice, but it doesn't necessarily make you a bad programmer.

- Eck

Here, read this.

https://google-styleguide.googlecode.com/svn/trunk/cppguide.html

Styling is also pretty important in coding as well. It helps readability, reduce the number of bugs occurred, reduces compiler errors, and can also help speed up your code.

Google's styling guide is pretty.... militaristic... but it's very simple to read quickly, and they have some pretty good practices. Like inlining getters and setters of classes.

Also... I have no freaking clue who's bright idea it was to teach people to write a function prototype in the same god dang file that the function it's self is in! The worst bit of this, is it's in the main file!

My personal opinion:
BEST: Separate function definitions from implementation.
Meh: Put functions and it's definitions at the very top of your main file.
PLAGUE: Prototype your functions in the main file. Then put the definition at the very end. Make us work for the code why don't you!?

My other suggestions would be to keep as little clutter out of your main file as much as possible. It's perfectly ok to move your functions into a separate header file. This example I am going to show you would be something that would probably get you screamed at in the professional enviorment... but for something this small... it'd be overkill to do it the proper way.


SomeHeader.h

#pragma once //This is basically a header guard. It prevents this file from being compiled more than once. Linker will link to this solitary instance.

// Notice how I detail the functions? This style lets
// Programmers know that this is the start of a new func
// when they are glancing through definitions.
/******************************************************
@Parameter- NONE
Function: Plays the game.
*******************************************************/

int play()
{
	int randomNumber = rand() % 100 + 1;
	int tries = 0;
	int guess;
	

	while (tries < 3)
	{
		cout << "Guess a number between 1 and 100: ";
		cin >> guess;
		if (guess == randomNumber)
		{
			cout << "Congrats you guessed correctly\n";
			return 1;
		}
		else if (guess < randomNumber)
		{
			cout << "You guessed too low try again\n";
			tries++;
		}
		else if (guess > randomNumber)
		{
			cout << "You guessed too high try again\n";
			tries++;
		}
	}
	cout << "The number was " << randomNumber << "\n";
	return -1;
}

/******************************************************
@Parameter:
   input Score Int: Recieves integer of player's score.
Function: Saves the game state
*******************************************************/

void save(int score)
{
	string name;
	cout << "Please enter you name: ";
	cin >> name;

	ofstream file;
	file.open("scores.txt",ios::app);
	if(file.is_open())
	{
		file << name << " " << score << "\n";
	}
	else
	{
		cout << "Unable to open file!!\n";
	}

	file.close();
}

. . .

You can then include the header, and remove the function prototypes.

------------

and I am trying to write a check that's a concise calculation between health, strength, perception, damage, and integrity.

Nope. One more thing needs to be said. I'm sorry I called you a bad programmer. :/ It's not a good practice, but it doesn't necessarily make you a bad programmer.

- Eck

very nice of you to realise that you did inadvertently describe me as a bad programmer.

i've been accused of trying to start fights,

i'm primarily an audio dsp coder, and the stalwarts in my field often code the same way i do. these people are not "game designers" who went to college to be part of a team, they are often engineers who do audio dsp on the side, and as an engineer, the important part of any task is GET IT DONE.

that's all.

as an audio dsp coder, i can direct you to *thousands* of documents written in the same style - *because that's how audio dsp generally gets written - "get the job done"*

you know how you read them? WITH EXTREME DIFFICULTY.

it's par for the course. audio dsp is a less open field than eg. graphics, but i'm telling you now, this is how many professionals code.

it's true, i have not released any games professionally. but if i were making a game for an iphone, with its simplistic interface, more than say 5000 lines is probably heading into bloat for the scope of a single activity kind of game eg. puzzle. short variable names are enough for one person working on one finite project.

heck i just made a fps "mech game" under 3000 lines, per user image.

these values are entirely a matter of scope and application, and not professionalism or ability.

I have removed the more egregious personal attacks against other users and current/former moderators from this thread. I expect that any subsequent discussion on programming style or advice for the original poster will proceed without such, as next time I will simply unapprove entire portions of the thread and warn offending users.

Keep things civil and on-topic please.

Nope. One more thing needs to be said. I'm sorry I called you a bad programmer. :/ It's not a good practice, but it doesn't necessarily make you a bad programmer.

- Eck

very nice of you to realise that you did inadvertently describe me as a bad programmer.

i've been accused of trying to start fights,

i'm primarily an audio dsp coder, and the stalwarts in my field often code the same way i do. these people are not "game designers" who went to college to be part of a team, they are often engineers who do audio dsp on the side, and as an engineer, the important part of any task is GET IT DONE.

that's all.

as an audio dsp coder, i can direct you to *thousands* of documents written in the same style - *because that's how audio dsp generally gets written - "get the job done"*

you know how you read them? WITH EXTREME DIFFICULTY.

it's par for the course. audio dsp is a less open field than eg. graphics, but i'm telling you now, this is how many professionals code.

it's true, i have not released any games professionally. but if i were making a game for an iphone, with its simplistic interface, more than say 5000 lines is probably heading into bloat for the scope of a single activity kind of game eg. puzzle. short variable names are enough for one person working on one finite project.

heck i just made a fps "mech game" under 3000 lines, per user image.

these values are entirely a matter of scope and application, and not professionalism or ability.

I might be misinterpreting what you're saying but is you argument, "Everyone else is doing it and its not great but I may as well do it too". While I get that, it seems more logical to realise the error (which you do seem to acknowledge) and attempt to fix. Rather than the just go along with it and add to the problem. Of course I may have misunderstood by what you meant there.

Here, read this.

https://google-styleguide.googlecode.com/svn/trunk/cppguide.html

Styling is also pretty important in coding as well. It helps readability, reduce the number of bugs occurred, reduces compiler errors, and can also help speed up your code.

Google's styling guide is pretty.... militaristic... but it's very simple to read quickly, and they have some pretty good practices. Like inlining getters and setters of classes.

Yes, but Google's style guides are mainly intended to stop 35,000 engineers consuming gaping great wadges of time having arguments about where the brackets go

Ah... but that's also an important aspect to remember in good programming!

I don't want to have an argument about using

? instead of if.

i consider my code to be concise and readable. other people hate it.

as an audio dsp coder, i can direct you to *thousands* of documents written in the same style - *because that's how audio dsp generally gets written - "get the job done"*

you know how you read them? WITH EXTREME DIFFICULTY.

Then, maybe it's not that readable, right?

In other industries we have learn that "getting the job done" often makes a lousy job that drags you and gets in the way of getting more work done.

I have downvoted you. Using two or three character variable names makes your code concise, but not readable. If you work in DSP maybe you have a point: most of your code would be highly mathematical, and if you keep your functions short (as in 4-5 lines at most, as Uncle Bob argues in Clean Code) and with really descriptive names, could be good enough. That wouldn't be good advice to give a newcomer who is asking for best practices, though.

This doesn't make you a bad programmer per se but it makes you one with whom I wouldn't want to work with.

If only you have to modify your code, whatever fits your taste. But don't try to sell this as a matter of opinion. Arguing about the size of classes and functions could have a point. Arguing that short variable names, as in old C, make code concise, could have a point. Arguing that two character variable names make code readable is just wrong, like saying that the sky is chocolate brown with green dots.

Have fun when you have to modify your readable programs after a couple of years, BTW.