Why conventions?

They let you take more for granted (by making one global decision rather than many local ones, you can concentrate on the more important characteristics of the code).
They help you transfer knowledge across projects. Similarities in names give you an easier and more confident understanding of what unfamiliar variables are supposed to do.
They help you learn code more quickly on a new project. Rather than learning that A's code looks like this and B's code looks like something else, you can work with a more consistent set of code.
so: any convention is usually better than no convention at all.

. . .

General advice

favor read time convenience over write time convenience
improve the parts you touch
if you can't figure out code: contact the author, don't work it out by yourself. In an ideal world the author will rewrite code and don't explain bad code.

. . .

. . .

changing the source without affecting the application. For example renaming variables or functions, re-arrangement of code etc.

save the code you start with
make list of steps you intend to take
keep refactorings small
do refactorings one at a time
make frequent checkpoints
the number of refactorings beneficial to a program is infinite -> 80/20 rule applies
define an interface between good code and ugly code

. . .