Блог пользователя nantf

Автор nantf, история, 5 лет назад, По-английски

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

  • Проголосовать: нравится
  • +29
  • Проголосовать: не нравится

»
5 лет назад, # |
  Проголосовать: нравится +6 Проголосовать: не нравится

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

»
5 лет назад, # |
  Проголосовать: нравится +34 Проголосовать: не нравится

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.

»
5 лет назад, # |
Rev. 2   Проголосовать: нравится +58 Проголосовать: не нравится

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

  • »
    »
    5 лет назад, # ^ |
      Проголосовать: нравится +26 Проголосовать: не нравится

    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.

  • »
    »
    5 лет назад, # ^ |
      Проголосовать: нравится +11 Проголосовать: не нравится

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

    • »
      »
      »
      5 лет назад, # ^ |
      Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

      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.

»
5 лет назад, # |
  Проголосовать: нравится +43 Проголосовать: не нравится

Start working.

»
5 лет назад, # |
  Проголосовать: нравится +36 Проголосовать: не нравится

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.

  • »
    »
    5 лет назад, # ^ |
      Проголосовать: нравится +9 Проголосовать: не нравится

    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!

    • »
      »
      »
      5 лет назад, # ^ |
        Проголосовать: нравится +23 Проголосовать: не нравится

      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.

»
5 лет назад, # |
  Проголосовать: нравится -37 Проголосовать: не нравится
$$$Leave \ my \ name \ in \ front \ of \ the \ fire.$$$
»
5 лет назад, # |
Rev. 3   Проголосовать: нравится +7 Проголосовать: не нравится

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.

»
5 лет назад, # |
Rev. 2   Проголосовать: нравится +55 Проголосовать: не нравится

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.

  • »
    »
    5 лет назад, # ^ |
      Проголосовать: нравится +4 Проголосовать: не нравится

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

    • »
      »
      »
      5 лет назад, # ^ |
        Проголосовать: нравится +31 Проголосовать: не нравится

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

      • »
        »
        »
        »
        5 лет назад, # ^ |
        Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

        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!

  • »
    »
    5 лет назад, # ^ |
    Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

    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.

    • »
      »
      »
      5 лет назад, # ^ |
        Проголосовать: нравится +38 Проголосовать: не нравится

      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.

      • »
        »
        »
        »
        5 лет назад, # ^ |
          Проголосовать: нравится +22 Проголосовать: не нравится

        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.

  • »
    »
    5 лет назад, # ^ |
      Проголосовать: нравится +6 Проголосовать: не нравится

    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.

    • »
      »
      »
      5 лет назад, # ^ |
        Проголосовать: нравится +51 Проголосовать: не нравится

      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.

»
5 лет назад, # |
  Проголосовать: нравится +9 Проголосовать: не нравится

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

»
5 лет назад, # |
  Проголосовать: нравится +20 Проголосовать: не нравится

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

»
5 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

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

»
5 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится

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