7 ms·

Seemed interesting up until the "Shortening code" section, that'd drive me mad.

by legohead 9y ago

slinger 9y ago
Why?
- chris11 9y ago
  Code should be written for readability, not typing speed.
  - thallium205 9y ago
    But if you're in a competitive environment that requires speed, why would you write for readability?
    - jack9 9y ago
      Because you probably have to re-read some, if not most, of the code while working through a solution.
    - saagarjha 9y ago
      Because you’ll end up debugging the code an hour later when it fails on an edge case?
      - kevmo314 9y ago
        The really good competitors won't make that sort of mistake...
  - victords 9y ago
    This is not production quality code that is running on some important business. It's competitive programming. Speed is the goal here.
    - gaius 9y ago
      This is not production quality code that is running on some important business. Then why is it used in the interview process for the latter?
      - thomasahle 9y ago
        I don't think code shortening is ever used for interview questions?
liveoneggs 9y ago
code golf is its own thriving subculture; and a lot of fun
svat 9y ago
Another reason for shortening code in programming contests (apart from being able to type and edit/iterate faster) is that it helps you avoid errors. For example, in the heat of the moment and under intense time pressure (e.g. you have finally figured out the algorithm to solve the problem, but you have only 13 minutes left to implement it or whatever), it's easy to write code like this: for (int i = 0; i < n; ++i) { for (int j = 0; i < n; ++j) { ... instead of what was intended (j < n). So if you have (in your pre-written library of snippets) a macro like #define FOR(i, n) for(int i = 0, _n = n; i < _n; ++i) then you can write: FOR(i,n) FOR(j,n) { ... (the _n in the macro is for cases like FOR(i, v.size()) to avoid recomputation) and at least avoid that particular error. Of course other sorts of silly errors are still possible; some examples here: https://www.quora.com/What-is-the-worst-mistake-youve-made-in-competitive-programming-What-did-it-cost-you https://www.quora.com/What-is-the-worst-mistake-youve-made-i...
- irundebian 9y ago
  I'm not sure that you avoid errors by forcing yourself to write short code. With C macros.
  - loup-vaillant 9y ago
    Here's a real world example: https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a852b4748097c4c7bfcf9d39ed2b7df#diff-a667a71187c131fe2449fa26edce6715L182 https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a... So I have this function, `crypto_wipe()` that wipes memory regions with `volatile` so the compiler doesn't optimises it away. In the link above I was using it thus: crypto_stuff(stuff_ctx *ctx) { // stuff crypto_wipe(ctx, sizeof(ctx)); // BUUUG!! } See the bug? I should have dereferenced `ctx` in the sizeof operator. As it was, was only wiping a pointer's worth of data instead of the whole structure. Oops. Now I write this instead: crypto_stuff(stuff_ctx *ctx) { // stuff WIPE_CTX(ctx); // correct! } The amount of repetition I avoid this way is almost negligible, but that was enough to trigger a mistake (I had quite a lot of wiping to do). With the macro, errors are much easier to spot (so much so that I am willing to give 100€ to anyone who finds such an error, see https://monocypher.org/quality-assurance/bug-bounty https://monocypher.org/quality-assurance/bug-bounty)

Seemed interesting up until the "Shortening code" section, that'd drive me mad.

slinger 9y ago

Why?

chris11 9y ago
Code should be written for readability, not typing speed.
- thallium205 9y ago
  But if you're in a competitive environment that requires speed, why would you write for readability?
  - jack9 9y ago
    Because you probably have to re-read some, if not most, of the code while working through a solution.
  - saagarjha 9y ago
    Because you’ll end up debugging the code an hour later when it fails on an edge case?
    - kevmo314 9y ago
      The really good competitors won't make that sort of mistake...
- victords 9y ago
  This is not production quality code that is running on some important business. It's competitive programming. Speed is the goal here.
  - gaius 9y ago
    This is not production quality code that is running on some important business. Then why is it used in the interview process for the latter?
    - thomasahle 9y ago
      I don't think code shortening is ever used for interview questions?

liveoneggs 9y ago

code golf is its own thriving subculture; and a lot of fun

svat 9y ago

Another reason for shortening code in programming contests (apart from being able to type and edit/iterate faster) is that it helps you avoid errors. For example, in the heat of the moment and under intense time pressure (e.g. you have finally figured out the algorithm to solve the problem, but you have only 13 minutes left to implement it or whatever), it's easy to write code like this: for (int i = 0; i < n; ++i) { for (int j = 0; i < n; ++j) { ... instead of what was intended (j < n). So if you have (in your pre-written library of snippets) a macro like #define FOR(i, n) for(int i = 0, _n = n; i < _n; ++i) then you can write: FOR(i,n) FOR(j,n) { ... (the _n in the macro is for cases like FOR(i, v.size()) to avoid recomputation) and at least avoid that particular error. Of course other sorts of silly errors are still possible; some examples here: https://www.quora.com/What-is-the-worst-mistake-youve-made-in-competitive-programming-What-did-it-cost-you https://www.quora.com/What-is-the-worst-mistake-youve-made-i...

irundebian 9y ago
I'm not sure that you avoid errors by forcing yourself to write short code. With C macros.
- loup-vaillant 9y ago
  Here's a real world example: https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a852b4748097c4c7bfcf9d39ed2b7df#diff-a667a71187c131fe2449fa26edce6715L182 https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a... So I have this function, `crypto_wipe()` that wipes memory regions with `volatile` so the compiler doesn't optimises it away. In the link above I was using it thus: crypto_stuff(stuff_ctx *ctx) { // stuff crypto_wipe(ctx, sizeof(ctx)); // BUUUG!! } See the bug? I should have dereferenced `ctx` in the sizeof operator. As it was, was only wiping a pointer's worth of data instead of the whole structure. Oops. Now I write this instead: crypto_stuff(stuff_ctx *ctx) { // stuff WIPE_CTX(ctx); // correct! } The amount of repetition I avoid this way is almost negligible, but that was enough to trigger a mistake (I had quite a lot of wiping to do). With the macro, errors are much easier to spot (so much so that I am willing to give 100€ to anyone who finds such an error, see https://monocypher.org/quality-assurance/bug-bounty https://monocypher.org/quality-assurance/bug-bounty)