For someone starting out in programming, you should learn the basic concepts. The human race has had 50+ years of programming computers as we know them and collectively we learnt a few things along the way. It helps to start out with knowing at least some of these 'gems' that have been accumulated otherwise you'll most likely learn them the hard way (like I have). What Russ was saying is perfectly true - there are some basic guidelines for writing 'good' code. If I told the junior engineers in my office all the list of 'rules' I have accumulated in my head they would be like poor RoboCop! (For those who haven't seen the RoboCop movie, in the second movie the social workers etc load him up with a new set of politically correct rules, so much so that he can do nothing. He throws himself on high voltage wires to erase all the rules. It then becomes a bad guy bloodbath.)If there are peformance issues or defects in 'good' code, it is a whole lot easier to address these rather than to struggle with a piece of poorly written code. How many times have we seen code posted on this forum that is poorly structed and the poster asks us 'tell me how to fix it' - that might be only 20 lines of code! The code is written in a manner that the person who wrote it doesn't understand it.
Had they followed a few of the basic rules, I'm sure they would've had more success.

Erik - sure there's ifs and buts for every rule. The examples you give are valid but very specific. With most of the code I've written, these might apply in <1% of the time and when they did apply, I'd most likely use them. If you're writing code that requires execution performance - then you write code from that perspective. Most of my stuff, that isn't the case. My last project spent about 70% of the time in the idle loop! Unless there's a specific case - one can't be too black and white about things so , I at least, tend to generalise.

Saif Ullah Khalid, in high level languages and assembler all variables are effectively 'global' as they all exist in the same memory space. However, it comes down the the 'usage' of the variables. In a high level language, you define the 'visibility' of a variable and the rules of the language enforce this 'visibility'. In assembler it comes down to the programmer to enforce these rules as well as using different file for the code and defining the 'visibility' in these. One piece of code I worked on was large (>200k object) and it had a database of configuration information. Each routine accesssed this directly. When we had to change the database we had to search out each and every access to this and change it. One would say this is 'global'. The database was stored in ram, what if we wanted to store it in a flash card? The solution here would be to use accesor routines. This alone would have saved countless programmer hours had it been done in the beginning. With routine names like 'get_input_database_ptr' would have made the code easier to read.