Re:Refactoring in C++: Top Techniques and Best Practices – T...
by jamesfinlayson on Thursday December 12, 2024 @11:56PM
(#42406022)
> 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.
Re:Refactoring in C++: Top Techniques and Best Practices – T...
by almostgotcaught on Friday December 13, 2024 @12:34AM
(#42406167)
> I thought this was a C 89 requirement too
TIL
Re:Refactoring in C++: Top Techniques and Best Practices – T...
by trealira on Friday December 13, 2024 @08:30AM
(#42408246)
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);
}
Re:Refactoring in C++: Top Techniques and Best Practices – T...
by jamesfinlayson on Sunday December 15, 2024 @06:12PM
(#42426631)
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.
Re:Refactoring in C++: Top Techniques and Best Practices – T...
by neverartful on Friday December 13, 2024 @09:22AM
(#42408632)
Also from those who learned with Pascal. Traditional Pascal requires that all variables be declared at top of procedure/function in a 'var' section.
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.