Once the code works, we have all the time in the world to make it look good.
If we need to make sudden rapid changes, then we have no choice other than messing up standard coding style.
Is this way professional and widely used? Or is it better to form the habit of maintaining perfect order while coding at every point in time?
It's easier to make it work if it's easy to read and you can see what's going on.
"Sudden rapid changes" create bugs in my experience!
Changes would be quicker and easier to make if the code was legible.
Seems like wasted time and inefficiency to me, revisiting the same code twice. Just my opinion, of course!
Once you decide on your coding style, it becomes natural, and doesn't take any longer to code neatly than it would to code scruffily...
I wouldn't really consider just typing out messy code - I tend to stick to the formatting standards the rest of the team are using.
Making use of an editor that enforces formatting helps, of course.
What usually happens is that, once the code works, something else urgent pops up. Then something else. Repeat until you can no longer remember how the original code works sufficiently well to be able to clean it up. If you ever get time to do that.
When you say "I'll fix it up later", you have to realise that "later" will probably never come...
It depends on what you are coding: a simple script or a full application and complex interlinking scripts/classes.
In the first case you can write code that works and then apply some simple reformat/refactoring based on your taste or not.
In the second case it is always better to follow strict formatting standards, code will be readable across the whole team and you won't have to do the same work twice.
I do agree with the general opinion - bugs appear as a result of quick fixes urgently required. Therefore you need to write a quick fix. After few of these your code becomes hardly maintainable. Also, after the project is ready for some short period (that doesn't require quick fixes for a week or two), the client rarely pays for additional changes and refactoring.