nantf's blog

By nantf, history, 4 weeks ago, In English,

For example, I have wanted to add whitespaces between operators and digits for a long time. But whenever I try it, it seriously slowed me down. That made me really awful.

For another example, I have a friend Layn. Let's take a look at his code(his recent submission on a Chinese OJ).

We've tried to make him change for a long time. But he didn't change at all.

So I wanted to ask how to improve the style and look of one's code?

(Also, how to make Layn change his code style?)

 
 
 
 
  • Vote: I like it
  • +29
  • Vote: I do not like it

»
4 weeks ago, # |
  Vote: I like it +6 Vote: I do not like it

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

»
4 weeks ago, # |
  Vote: I like it +34 Vote: I do not like it

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.

»
4 weeks ago, # |
Rev. 2   Vote: I like it +58 Vote: I do not like it

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 :)

  • »
    »
    4 weeks ago, # ^ |
      Vote: I like it +26 Vote: I do not like it

    Really thank you! I think I just have not enough effort on this before.

    And "give your code to other people" is a good idea. I think my friend needed that too.

  • »
    »
    4 weeks ago, # ^ |
      Vote: I like it +11 Vote: I do not like it

    I don't think 10fastfingers matters a lot. My best on 10FF is 144 WPM, but my actual coding speed is slow because I only know where the letters are, not other characters like <>. I use my ring finger for the semicolon, not my pinky :(

    • »
      »
      »
      4 weeks ago, # ^ |
      Rev. 2   Vote: I like it 0 Vote: I do not like it

      The location of the other characters are really hard to remember! I often need to look at my keyboard to get where they are. Maybe we need not only typing but much coding to improve our coding speed.

      • »
        »
        »
        »
        4 weeks ago, # ^ |
          Vote: I like it 0 Vote: I do not like it

        Even better, I just realized that you can create a custom typing test on 10FF. That means you can just enter special characters and voila!

»
4 weeks ago, # |
  Vote: I like it +43 Vote: I do not like it

Start working.

»
4 weeks ago, # |
  Vote: I like it +36 Vote: I do not like it

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.

  • »
    »
    4 weeks ago, # ^ |
      Vote: I like it +9 Vote: I do not like it

    Yeah, I often fail to detect those stupid typos because the characters are too close to each other.

    But though my friend knows the drawbacks of coding such unreadable codes, he doesn't want to change it. (He says this is "beautiful", and he doesn't think changing the style would help him debug. We have tried to persuade him for a long time but nothing happens.)

    Anyway I got that. Thank you for helping me!

    • »
      »
      »
      4 weeks ago, # ^ |
        Vote: I like it +23 Vote: I do not like it

      Yeah, I feel like it's not going to change until he loses something important because of this. Unless you offer money to him to write better or something like that.

»
4 weeks ago, # |
  Vote: I like it -37 Vote: I do not like it
$$$Leave \ my \ name \ in \ front \ of \ the \ fire.$$$
»
4 weeks ago, # |
Rev. 3   Vote: I like it +7 Vote: I do not like it

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.

»
4 weeks ago, # |
Rev. 2   Vote: I like it +55 Vote: I do not like 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.

  • »
    »
    4 weeks ago, # ^ |
      Vote: I like it +4 Vote: I do not like it

    In China, the OI players think that the speed of the program is more important.

    • »
      »
      »
      4 weeks ago, # ^ |
        Vote: I like it +31 Vote: I do not like it

      As discussed below in some comments, the speed is exactly the same.

      I wanted to add a resource that might be useful, this "What Has My Compiler Done for Me Lately?" talk from CppCon 2017 discusses this and other compiler optimizations (the discussion about m<<1 and 2*m starts at 29:32).

      • »
        »
        »
        »
        4 weeks ago, # ^ |
        Rev. 2   Vote: I like it 0 Vote: I do not like it

        Thank you for your help. I tried m<<15 and m*32768 , m&1 and m%2 and so on, they are often in the same speed, but sometimes the latter are in the faster speed. Even I don't compiled to assembly with -O2, the result doesn't change. It shocked me!

  • »
    »
    4 weeks ago, # ^ |
    Rev. 2   Vote: I like it 0 Vote: I do not like it

    Chinese people like to use m<<1 because it is a little faster than 2*m and we have tighter TL. Maybe they are the same in other people's mind but most of Chinese OI players are taught to use m<<1 instead of 2*m.

    • »
      »
      »
      4 weeks ago, # ^ |
        Vote: I like it +38 Vote: I do not like it

      It's the exact same, maybe it's different in some edge cases. Compilers are really smart and can optimize trivialities like this. As a short experiment, I took 57273639, compiled to assembly with -O2, then replaced 2 * n with (n << 1) and compiled again to assembly with -O2. The resulting assembly was identical.

      • »
        »
        »
        »
        4 weeks ago, # ^ |
          Vote: I like it +22 Vote: I do not like it

        I see now. I tried it just now and surprisely found they are almost in the same speed! Now I wonder why my teachers often told us to use n<<1.

  • »
    »
    4 weeks ago, # ^ |
      Vote: I like it +6 Vote: I do not like it

    For me, I use it mostly because I like how it looks, but it also has some small benefits, like in segment tree, it's easier for me to write md = l + r >> 1 than md = (l + r) / 2, and it works for when l and r can be negative while /2 doesn't (output of printf("%d %d\n", -1 >> 1, -1 / 2); is -1 0).

    As for readability, the only place where I think it may cause problems is when using it in mathematical equations, so I try to use the normal *2 there.

    • »
      »
      »
      4 weeks ago, # ^ |
        Vote: I like it +51 Vote: I do not like it

      Things like l + r >> 1 are very uncomfortable to read. Or maybe it's just me, who used to interpret + as a low priority operation.

»
4 weeks ago, # |
  Vote: I like it +9 Vote: I do not like it

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).

»
4 weeks ago, # |
  Vote: I like it +20 Vote: I do not like it

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

»
4 weeks ago, # |
  Vote: I like it 0 Vote: I do not like it

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 ).

»
4 weeks ago, # |
  Vote: I like it 0 Vote: I do not like it

Fortunately, wxp didn't see his code or we would never see him again (wxp is our coach)

»
4 weeks ago, # |
  Vote: I like it -8 Vote: I do not like it

I explain my coding I think above code looks good,it is small and easy to follow.Putting brackets another line will also make it better.Also , I started to do more on one line than doing it over many lines.

»
4 weeks ago, # |
  Vote: I like it 0 Vote: I do not like it

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