When you are new it is usually a good idea to take some time to observe the dynamics and get a feel for the team, etc before taking it upon yourself to make any big changes. A good rule of thumb is "If it ain't broke, dont fix it", or a corollary to that, "If it was broken, someone would have fixed it by now." If the code in question was a big issue, it probably would (or at least should have been fixed by now. It is possible that some code you come across at this job will need fixing, but wait until you are more familiar with the group's system before you decide if any such code qualifies.

Despite how much effort goes into developing universal coding/documentation standards, EVERY WORKPLACE WILL HAVE THEIR OWN STANDARDS and it takes time to infer what exactly what those will are.

When you are new it is usually a good idea to take some time to observe the dynamics and get a feel for the team, etc before taking it upon yourself to make any big changes. A good rule of thumb is "If it ain't broke, dont fix it", or a corollary to that, "If it was broken, someone would have fixed it by now." If the code in question was a big issue, it probably would (or at least should have been fixed by now. It is possible that some code you come across at this job will need fixing, but wait until you are more familiar with the group's system before you decide if any such code qualifies.

Despite how much effort goes into developing universal coding/documentation standards, EVERY WORKPLACE WILL HAVE THEIR OWN STANDARDS and it takes time to infer what exactly what those are.