I am going to strongly agree with funkymushroom's answer. If you are a team environment make sure others know you are refactor or reorganizing code, if you ever plan to get any good future assignments.
From personal experience I know, while not your style of coding, if you are maintaining code, which other also modify and maintain, stay in the style of the existing code. Adding comments and clarification is fine, but the basic layout and conventions should remain. The old gurus/guns on the project expect the code to be similar to what they have been seeing for years.
When a customer is screaming about a bug, your management will go to the old guns to fix the problem as quick as possible. If these old guns, when under pressure, find you “cleaned up the code” and so they now have to spend time figure out where you moved or renamed that one variable they know needs tweaking, your name in the company will be changed to “mud”.
Once the crisis is over, first the old gun will blame you slowly down the critical update. Next you will find that you get to keep maintain the cleaned up code for as long as you are at the company. Finally, when new interesting projects become available, your managers will ask to the gurus on who should work the project, and if you have screwed them once, you will never make it to the new project, until your fodder being thrown in at the end to meet a deadline.
If you learned in college the “right” way to code, and you are now in the workforce, forget that “right” way. These are not college assignment, these projects don’t last just a semester, they can live for years, and will have to be maintained by a group of people with different levels expertise and different levels of interest in the latest CS trend. You have to be a team player.
You can be the biggest hot shot programming in school, but in the work place, your first job, you a newbie with zero street cred. People who have been programming for years don’t give a hoot about your school or grades, it is how well do you play with others and how much disruption you bring to their lives.
In my 20 years, I have seem multiple ace programmers fired, mainly because they demand to do things their “right” way. Unless you bring something very, very, very unique to the job, you are replaceable. You may have been top of your class, but next year, someone else will be top of their class, and looking for a job.
I look at it as your primary job, is to keep your job, until you decide to change jobs. To keep your job means you have to play nice in the playground someone else built and paid for.
I know I sound negative, but there is always hope. As you gain experience, have success, you will gain influence, and be able to shift things to a better way. When writing new code or on a new project, push for the changes you seek. If it is new code, the old guns don’t expect it to be the way they left it, and when they see the advantages they might learn and adapt the new way.
Old system can change, but it takes time. Changing something introduces risk, and business hate risk, and you have to take time and work to make the company comfortable with the change.