Auto comment: topic has been updated by nantf (previous revision, new revision, compare).

I realize that he really like to put many lines in one line (which we call "压行" in Chinese). In my opinion the style is very bad for coding and debuging.

This is a question I can answer, since in french training camps, coaches put a lot of emphasis on code quality and readability ("writing over debugging")

There is no magic here, if you really want a nice code style, you have to force yourself to follow some basic rules. It might be disturbing at the beginning but I'm sure you'll quickly adapt yourself.

First of all, you should always think how you will implement your solution, before actually coding it.

Write on a paper all rules you should follow (meaningful names, spaces, constants instead of magic numbers, each line is self-explanatory, split long formulas into variables, etc.) and when you practice, code slowly with these rules in mind.

During practice, you should never submit (or even try to compile) a code which doesn't meet all these rules.

Once your style begins to become acceptable, you should give your code to other people, eventually explain your conventions, and then see if they can understand it.

It might make you a bit slower, but the time lost while coding is negligible (except if you type slowly, in that case try to improve your typing speed on 10fastfingers for example, I'm around 100 WPM). You'll surely save a lot of time during debugging.

And, very important, don't forget to be proud of the code you wrote after all these efforts :)

Start working.

How to improve your own style? Pick any reasonable style guide, e.g. Google's and stick to it.

How to make someone else do it? You need to understand why good style and good coding practices are important in the first place.

I think even in competitive programming you want your code to be readable. You might think that because you never need to see the code again it's not important. But consider the following: you're on a 5-hour contest, at first you solve something, get WA, move to other problems. Then near the end you realize the mistake and try to fix it. But because your code is messy you waste a lot of time trying to understand your code before you can add the fix.

Also as implementation becomes longer, you lose your handle on what is going on in your code. If you use variable names like qpz it's really easy to make stupid mistakes like mixing up two different variables and assigning to the wrong thing.

Also, in the implementation you show, it's very hard to detect stupid typos like i vs 1. They stand out better if the code would use lines properly.

Other "best practices" are important too. Global state is still evil and several times I have gotten WA because I forgot to initialize something in a problem with multiple tests. It's often really hard to debug too. In general if a best practice avoids a hard-to-debug bug, it's rational to use it.

But I think most people will not care and only change if they learn those things "the hard way", for example losing a medal in an important contest because of a mistake that's avoidable with good practices.

Layn is my friend too. He's coding skill is very 'good' (but I can't understand his code). I think he just need a chance to change, but he never recognize it.

At least he used a for-loop over i instead of copy-pasting :>

And I can't comprehend why people use m<<1 instead of 2*m. Come on, the latter is so much easier to understand (and there is no difference in running time here). Remember that you will eventually want others to understand your code.

Type faster and all these things that slow you down will suddenly become a blink of an eye. Also, use descriptive variable names. Note that if you are used to typing fast in english, you will not want to write some random abbreviation like nxt instead of next, since it actually slows you down (brain has to process this new weird spelling as opposed to well known next spelling. Just like how typing random string precisely is much harder than typing english word).

Another suggestion is to use modern IDE (e.g. CLion), they all have autoformat feature. Just press the hotkey from time to time.

I don't think whatever you do ; Layn will ever change his coding style... Come on... everyone makes silly bugs while writing even small implementations ; but if someone can write so horribly like that and still pull it off ; and to him that is easy to debug... I can understand how much false pride that person might have collected...

You can't make him change. -is-this-fft- is correct ; he can only learn the hard way ( Or the greedy way if you pay him XD ).

Look up for Google style guide in the language you prefer.