5 ms·

Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in yo

by TeeWEE 6y ago

Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in your code, nor in your comments. Lets keep things professional.

adewinter 6y ago
If you do the above, your prod servers will always run in "deprecated allow" mode because developers continue to use (and add new) deprecated functionality. That's what the article is attempting to tackle. Why not use profanity in code? We're all adults.
- Spivak 6y ago
  Prod should always be running in allow mode anyway for the same reason that prod builds compile out debug asserts and static type checks. Once the code passes review and makes it into prod you've already lost and spitting out warnings on every function invocation will just piss off your ops team.
  - adewinter 6y ago
    Right. So what's the point of having @deprecated tags and a deprecated fail mode if you can't ever use it?
    - gowld 6y ago
      Tests.
    - Spivak 6y ago
      Okay, so first you have to have a whitelist of "allowed" usages of depreciated functionality for this to actually work. Anything that makes it into prod goes on the whitelist. All dev environments, QA, and your automated testing run with fail mode on and trying to push code that adds to the whitelist should set off alarm bells. From there it's up to the team / business if it's worth doing it anyway.
    - TeeWEE 6y ago
      You use it when testing and you can turn deprecation flags on and off. Even on a single production machine/vm.
- philwelch 6y ago
  > Why not use profanity in code? We're all adults. You just answered your own question there.
  - adewinter 6y ago
    I think you're saying adults do not use profanity, but that doesn't really make sense.
    - gowld 6y ago
      Adults use words appropriately, not spamming profanity to the point that it's meaningless.
      - wizzwizz4 6y ago
        If it's “meaningless”, its not profanity. I don't see your point.
- TeeWEE 6y ago
  You can run tests in deprecation not-allow mode. You can run a single VM in deprecation not allow mode. I understand that naming features as not supported also makes sense. But to me that is what feature toggles are for.
raverbashing 6y ago
You would need a "deprecated light warn" and a "deprecated heavy warn" modes as well. Then you can go step by step
Spivak 6y ago
I feel like the profanity rule could go either way. If your team has a culture of casual profanity then go for it. Something like "listen here you little shit" can be lighthearted and funny in the right context. Profanity is a smoke test for anger which is the thing you need to actually avoid.
zaphar 6y ago
Change the name to BannedList or something and keep it as is. No profanity and developers get failing tests immediately when they consume a deprecated API. The core principle no matter what you call it is a good one.

by TeeWEE 6y ago

adewinter 6y ago

If you do the above, your prod servers will always run in "deprecated allow" mode because developers continue to use (and add new) deprecated functionality. That's what the article is attempting to tackle. Why not use profanity in code? We're all adults.

Spivak 6y ago
Prod should always be running in allow mode anyway for the same reason that prod builds compile out debug asserts and static type checks. Once the code passes review and makes it into prod you've already lost and spitting out warnings on every function invocation will just piss off your ops team.
- adewinter 6y ago
  Right. So what's the point of having @deprecated tags and a deprecated fail mode if you can't ever use it?
  - gowld 6y ago
    Tests.
  - Spivak 6y ago
    Okay, so first you have to have a whitelist of "allowed" usages of depreciated functionality for this to actually work. Anything that makes it into prod goes on the whitelist. All dev environments, QA, and your automated testing run with fail mode on and trying to push code that adds to the whitelist should set off alarm bells. From there it's up to the team / business if it's worth doing it anyway.
  - TeeWEE 6y ago
    You use it when testing and you can turn deprecation flags on and off. Even on a single production machine/vm.
philwelch 6y ago
> Why not use profanity in code? We're all adults. You just answered your own question there.
- adewinter 6y ago
  I think you're saying adults do not use profanity, but that doesn't really make sense.
  - gowld 6y ago
    Adults use words appropriately, not spamming profanity to the point that it's meaningless.
    - wizzwizz4 6y ago
      If it's “meaningless”, its not profanity. I don't see your point.
TeeWEE 6y ago
You can run tests in deprecation not-allow mode. You can run a single VM in deprecation not allow mode. I understand that naming features as not supported also makes sense. But to me that is what feature toggles are for.

raverbashing 6y ago

You would need a "deprecated light warn" and a "deprecated heavy warn" modes as well. Then you can go step by step

Spivak 6y ago

I feel like the profanity rule could go either way. If your team has a culture of casual profanity then go for it. Something like "listen here you little shit" can be lighthearted and funny in the right context. Profanity is a smoke test for anger which is the thing you need to actually avoid.

zaphar 6y ago

Change the name to BannedList or something and keep it as is. No profanity and developers get failing tests immediately when they consume a deprecated API. The core principle no matter what you call it is a good one.