3 ms·

This is a little light on actual content. The best practices are: 1) do it in small steps 2) use version control 3) use automated tests 4) make sure the co

This is a little light on actual content. The best practices are: 1) do it in small steps 2) use version control 3) use automated tests 4) make sure the code is readable. Pretty straight forward.

almostgotcaught 2y ago
here's one that a teammate taught me - const everything that can be const and then slowly undo the consts when necessary. it'll reveal lots of stupid implicit state spaghetti. const methods for the OOP flavor of spaghetti. another one is move variables as close to their use as possible. so many people somehow inherited FORTRAN style (from where! you're younger than me!) and declare variables at the top of a function. that's a brilliant way to either forget to use/remove/initialize them and/or shadow names. drives me utterly insane (because it's like who the hell is teaching people this). also probably -Werror or -Wall depending on the size of the code base (at least -Werror=return-type, -Werror=unused-variable, -Wunused-but-set-variable, -Werror=dangling). > use version control yea lots and lots of incremental commits with decent commit messages purely for you to remember what ground you covered. also lots of branches and rebasing. what a chore but it's the only way to stay sane. > make sure the code is readable debatable but my first move is to undo all the spaghetti OOP and "please break out into a function" bullshit. less readable to the junior maybe but much more readable to a senior that needs to actually understand what the entire module is doing. C++ is fine language - most people just are really bad at it.
- jamesfinlayson 2y ago
  > so many people somehow inherited FORTRAN style (from where! you're younger than me!) and declare variables at the top of a function. I thought this was a C 89 requirement too, and I thought until recently that some Linux distros lifted the build requirement to C 99. I've worked on a few code bases with all the variables declared at the top of a function though and you're absolutely right - plenty of variables that end up unused or shadowed.
  - almostgotcaught 2y ago
    > I thought this was a C 89 requirement too TIL
    - trealira 2y ago
      It's not a C89 requirement. C89 requires variables to be declared at the top of a block, not a function. So, you could write things like this: while (...) { int a = 1, b = 2, c = 3; printf("%d\n", a + c - b); }
      - jamesfinlayson 2y ago
        Ah okay - I misremembered - I only had to work with strict C89 once and that was close to 15 years ago now, and at a similar time I inherited a codebase that did things the C89 way but it was compiled as C++ so with no enforcement of variables at the top of blocks I didn't really pay attention to where things had been declared when it was first written.
  - neverartful 2y ago
    Also from those who learned with Pascal. Traditional Pascal requires that all variables be declared at top of procedure/function in a 'var' section.
rramadass 2y ago
5) Use "asserts" liberally to check program state.

This is a little light on actual content. The best practices are: 1) do it in small steps 2) use version control 3) use automated tests 4) make sure the code is readable. Pretty straight forward.

almostgotcaught 2y ago

here's one that a teammate taught me - const everything that can be const and then slowly undo the consts when necessary. it'll reveal lots of stupid implicit state spaghetti. const methods for the OOP flavor of spaghetti. another one is move variables as close to their use as possible. so many people somehow inherited FORTRAN style (from where! you're younger than me!) and declare variables at the top of a function. that's a brilliant way to either forget to use/remove/initialize them and/or shadow names. drives me utterly insane (because it's like who the hell is teaching people this). also probably -Werror or -Wall depending on the size of the code base (at least -Werror=return-type, -Werror=unused-variable, -Wunused-but-set-variable, -Werror=dangling). > use version control yea lots and lots of incremental commits with decent commit messages purely for you to remember what ground you covered. also lots of branches and rebasing. what a chore but it's the only way to stay sane. > make sure the code is readable debatable but my first move is to undo all the spaghetti OOP and "please break out into a function" bullshit. less readable to the junior maybe but much more readable to a senior that needs to actually understand what the entire module is doing. C++ is fine language - most people just are really bad at it.

jamesfinlayson 2y ago
> so many people somehow inherited FORTRAN style (from where! you're younger than me!) and declare variables at the top of a function. I thought this was a C 89 requirement too, and I thought until recently that some Linux distros lifted the build requirement to C 99. I've worked on a few code bases with all the variables declared at the top of a function though and you're absolutely right - plenty of variables that end up unused or shadowed.
- almostgotcaught 2y ago
  > I thought this was a C 89 requirement too TIL
  - trealira 2y ago
    It's not a C89 requirement. C89 requires variables to be declared at the top of a block, not a function. So, you could write things like this: while (...) { int a = 1, b = 2, c = 3; printf("%d\n", a + c - b); }
    - jamesfinlayson 2y ago
      Ah okay - I misremembered - I only had to work with strict C89 once and that was close to 15 years ago now, and at a similar time I inherited a codebase that did things the C89 way but it was compiled as C++ so with no enforcement of variables at the top of blocks I didn't really pay attention to where things had been declared when it was first written.
- neverartful 2y ago
  Also from those who learned with Pascal. Traditional Pascal requires that all variables be declared at top of procedure/function in a 'var' section.

rramadass 2y ago

5) Use "asserts" liberally to check program state.