4 ms·

Thanks for the clarification. I guess the tools you had available at that time would affect the severity of this. Nowadays, with the ability to refactor a macro

Thanks for the clarification. I guess the tools you had available at that time would affect the severity of this. Nowadays, with the ability to refactor a macro name in a few seconds, I wouldn't necessarily agree that a developer that used a silly name would "never make it to a senior developer". Fuck, I'm "senior" and I definitely use worse variable names on a regular basis.

sokoloff 6y ago
I think I disagree strongly on the first point. If SEVENTEEN is used instead of MENU_SCALING_FACTOR and ARBITRARY_OTHER_THING (two semantically different things both happening to be 17), no refactoring tool (that I’m aware of) is going to be able to tease apart just the former use and amend it to 23, leaving ARBITRARY_OTHER_THING as 17. const int declarationAdoptedYear = SEVENTEEN * HUNDRED + THIRTY_EIGHT * TWO;
- stagger87 6y ago
  I use QtCreator and it would be able to do this. If I had #define SEVENTEEN 17 and another macro #define OTHER_THING 17 I could simply refactor SEVENTEEN to #define MY_NEW_NAME 17 which would change all occurrences of SEVENTEEN to MY_NEW_NAME, and then I would just change the value of that macro. #define MY_NEW_NAME 23
  - sokoloff 6y ago
    But the devs who would define SEVENTEEN to be 17 are unlikely to define OTHER_THING at all, since there’s a “perfectly good” macro that evaluates to 17 and avoids hard-coded numbers already. (They might even cite DRY: Don't Repeat Yourself as a misapplied best-practices shibboleth.) See the (contrived) Declaration of Independence line above. Your editor would dutifully change the date to be off by six hundred years.
    - stagger87 6y ago
      Sure, I understand what you mean. To be honest, that sounds like a different issue, one that would arise after additional circumstances took place. I still stand by my initial comment, that if you had the quick ability to refactor SEVENTEEN at the time this developer committed this, it wouldn't be a very big deal, and this developer could be told that good variable names are important and he wouldn't be stuck as a junior developer forever, lol.
deleted 6y ago
[deleted]

sokoloff 6y ago

I think I disagree strongly on the first point. If SEVENTEEN is used instead of MENU_SCALING_FACTOR and ARBITRARY_OTHER_THING (two semantically different things both happening to be 17), no refactoring tool (that I’m aware of) is going to be able to tease apart just the former use and amend it to 23, leaving ARBITRARY_OTHER_THING as 17. const int declarationAdoptedYear = SEVENTEEN * HUNDRED + THIRTY_EIGHT * TWO;

stagger87 6y ago
I use QtCreator and it would be able to do this. If I had #define SEVENTEEN 17 and another macro #define OTHER_THING 17 I could simply refactor SEVENTEEN to #define MY_NEW_NAME 17 which would change all occurrences of SEVENTEEN to MY_NEW_NAME, and then I would just change the value of that macro. #define MY_NEW_NAME 23
- sokoloff 6y ago
  But the devs who would define SEVENTEEN to be 17 are unlikely to define OTHER_THING at all, since there’s a “perfectly good” macro that evaluates to 17 and avoids hard-coded numbers already. (They might even cite DRY: Don't Repeat Yourself as a misapplied best-practices shibboleth.) See the (contrived) Declaration of Independence line above. Your editor would dutifully change the date to be off by six hundred years.
  - stagger87 6y ago
    Sure, I understand what you mean. To be honest, that sounds like a different issue, one that would arise after additional circumstances took place. I still stand by my initial comment, that if you had the quick ability to refactor SEVENTEEN at the time this developer committed this, it wouldn't be a very big deal, and this developer could be told that good variable names are important and he wouldn't be stuck as a junior developer forever, lol.

deleted 6y ago

[deleted]