I have my first real job as programmer, but I can't solve any problems because of the coding style used. The code here:Does not have commentsDoes not have functions (50, 100, 200, 300 or more lines executed in sequence)Uses a lot of if statements with a lot of pathsHas variables that make no sense (eg.: cf_cfop, CF_Natop, lnom, r_procod)Uses an old language (Visual FoxPro 8 from 2002), but there are new releases from 2007.I feel like I have gone back to 1970. Is it normal for a programmer familiar with OOP, clean-code, design patterns, etc. to have trouble with coding in this old-fashion way?EDIT: All the answers are very good. For my (un)hope, appears that there are a lot of this kind of code base around the world. A point mentioned to all answers is refactor the code. Yeah, I really like to do it. In my personal project, I always do this, but... I can't refactor the code. Programmers are only allowed to change the files in the task that they are designed for. Every change in old code must be keep commented in the code (even with Subversion as version control), plus meta information (date, programmer, task) related to that change (this became a mess, there is code with 3 used lines and 50 old lines commented). I'm thinking that is not only a code problem, but a management of software development problem.
I can't program because the code I am using uses old coding styles. Is this normal to programmers?
coding style
This sounds to me like an Opportunity. It's clear that you already can see lots of problems in how things are done and managed. You can either complain that it's all rubbish and that you can't do anything, OR you can use this as a golden opportunity to really show your employer your worth.Now, it's not going to help you if you march up to your employer and tell him that everything needs to change.  So the trick is to play along for a while, ask LOTS of questions, and when you are required to write code you'll need to play by their rules with all of the comments etc, as you are going to need to keep other developers informed using whichever system they presently prefer, while at the same time you can introduce sensible refactorings that won't risk you anything. You can extract a couple of methods, and if your language supports it, introduce a few unit tests.  When asked why you've done it this way, or if told you're doing something wrong, avoid getting defensive or argumentative while making a sound presentation of your position for your preferred style of coding.  For example, you can refer to books such as Bob Martin's Clean Code, or you can refer to other books, articles, or even questions and answers that you have come across on Programmers.SE.  Anything that you can find helpful to support your position with facts that might be beyond your experience in the eyes of the people you are working with.With regards to the excessive commenting, some of this can be cleared up if you were to add in a few descriptive names for the variables and methods, but you might also be able to make a case for a good version control system, and using that to keep the record of the changes and dates etc, and for the use of a tool to compare the different versions of your source files if one doesn't already come with your chosen VCS.Like I said, this is an opportunity to contribute to the improvement of a development team that sounds like it's kind of lost its way so to speak.  You have the opportunity to stand out as skilled and knowledgeable, and as someone who can lead by example. These are all good things to help you later as your career progresses.