C30N9

I can only agree the comments above. Programming first, games after that. Somehow, it was not hard for me after a certain point, and even though I'm way not a professional, now I'm on the level where I can even enjoy programming!

fraggle, thanks for the "portfolio" hint, never thought that I can utilize my hobby projects this way.

This is my very first C++ project:

code:
Array

You might notice TheNumber isn't actually used.

Katamori said:

fraggle, thanks for the "portfolio" hint, never thought that I can utilize my hobby projects this way.

No problem. I can't emphasize how useful hobby projects have been in my career. As a quick summary:

• When I applied to University, I had written SMMU and described it and FraggleScript on my University application. When I was called in for an interview at the University I had applied to, it was the first thing they asked me about.
  
• One summer at University I did a summer job as a research assistant. When applying, I listed ~3 hobby projects that were related to the job and they gave it to me without even bothering to interview me.
  
• I've listed hobby projects on my resume for every job I've applied for since then.
  

I really believe it makes a big difference - whether you want to work in games or not. Interviewers have noted that it demonstrates a personal interest in programming / software development.

C30N9 said:

This is my very first C++ project:

Congratulations! This is exactly the kind of task you should be taking on for learning programming. I know it's not as large scale as making a 3D game but you really do need to start small.

If you don't mind I have some suggestions for how you can write better code. I hope you'll find these helpful.

• Firstly, pay attention to the formatting of your code. It might seem kind of anal but it's actually really important. Indenting your code makes it more readable. For example, here's a chunk from your code:
  

  code:
  Array
  

  If you instead write it like this:
  

  code:
  Array
  

  Do you see how that's more readable? Just from a glance you can see that the 'cin >>...' line is at the same 'depth' as the 'if (TF ...' line. Indenting the contents of the if() block means that you can see that code is at a different depth. When you have a larger program you'll find that these kinds of visual cues become really important.
  
  You also put some blocks on multiple lines, some all on one line, for example:

  code:
  Array
  

  Try to stay as consistent as possible when laying out your code. If a block contains more than one statement (the above contains two) then it should definitely be split onto multiple lines.
  
  
• You use the goto statement in your program. It is almost always a bad idea to use the goto statement. There are some exceptional situations in which it is acceptable to use it, but there aren't many. Quite a few modern languages (Java, Python, etc.) actually deliberately do not have a goto statement because it is considered so bad.
  
  The reason that it's a bad idea to use goto is that it leads to code that is difficult to follow - code with lots of gotos is sometimes called 'spaghetti code' because there are many different intersection paths. It should always be possible to structure your code to use eg. a loop instead of a goto. It might seem like a goto is easier to add, but using a loop forces you to structure your code better.