• (nodebb)

    That's the frist lesson about communication: misunderstandings are the rule, not the exception!

  • TheCPUWizard (unregistered)

    One of my pet peeves... deprecate does NOT mean OBSOLETE, nor does it mean that there is a planned end of support, nor removal of the item... It means "recommended not to use" without their being a reason given.

  • Sauron (unregistered)

    As a bonus, renaming PopulateOfferNodes() to OBSOLETE_PopulateOfferNodes() means they had to replace every call.

    Either they did it manually by copy-pasting the OBSOLETE_ prefix (possibly forgetting some occurrences, or pasting at the wrong place, etc) , or they did a big application-wide string replace, in which case they could do a lot of dawizard to the codebase, if ever there are other functions named stuffs like PopulateOfferNodesTurboencabulator() or CancelPopulateOfferNodes() .

  • (nodebb) in reply to Sauron

    Depending on their project structure, they may be able to use refactoring to "rename" these methods, which automatically changes the declaration and all usages, taking care of the overload resolution, instance vs static, etc. - it actually knows which method is being renamed. Prefixing method names with "OBSOLETE_" is still extremely stupid, but text find/replace is not the only way to do.

    Addendum 2024-04-23 09:17: PS. Furthermore, even the text find/replace has "match whole words" feature in most modern text editors, let alone the full Visual Studio. They can also find ".PopulateOfferNodes(" to make sure they're replacing call sites.

  • (nodebb)

    I suppose the HR department in this organization doesn't discipline or terminate bad employees, instead prefixes their names with "IDIOT_" or "FIRED_", as necessary.

  • see sharp (unregistered)

    Definitely two if not three WTFs for the price of one... first and obviously, the developer's training gap for likely not being aware of the [Obsolete] annotation, arguably second for failing to clarify the intended action because prefixing so obviously looks like a bad idea, and finally the failure to catch in code review.

  • (nodebb) in reply to see sharp

    and finally the failure to catch in code review.

    I do not find it plausible that a real code review actually happened.

  • (nodebb)

    As a bonus, renaming PopulateOfferNodes() to OBSOLETE_PopulateOfferNodes() means they had to replace every call.

    Which is ridiculous considering that the point of the Obsolete attribute is to create a transition windows where we progress from "you get a message to modify your code" to "your code won't compile, but previously compiled versions still run" to "it's now broken".

    Renaming the method jumps us straight to broken code. No one will ever see a message, no one will ever be told what their options are. That's neither deprecated nor obsoleted, that's removed.

    The only worse choice would be to replace the function body with: throw new Exception("I hate you")

  • Sou Eu (unregistered)

    I program mostly in Java. Java introduced annotations in version 5; when did C# get annotations? Maybe the developer wasn't aware of them.

  • Yazeran (unregistered) in reply to Jaime

    The only worse choice would be to replace the function body with: throw new Exception("I hate you")

    That is a Brillant approach, we should all embrace this simple solution! Evil Grin

    Yazeran

  • (author) in reply to Sou Eu

    Attributes have been there since C# 1.0.

  • (nodebb) in reply to see sharp

    And possibly also the architect who didn't say what he really wanted done. If he had said "Please put [Obsolete] annotations on functions X, Y, Z", the whole issue would likely have been avoided.

  • (nodebb) in reply to Steve_The_Cynic

    And that's exactly what this coder has done. Oh, you mean [Obsolete], not OBSOLETE_? You should've pronounced these brackets better back then.

  • Duke of New York (unregistered)

    As if anyone looks at compiler warnings. 🙄

  • (nodebb) in reply to see sharp

    If you have worked in .net for a awhile, it's nearly impossible to not come around ObsoleteAttribute. As soon as you use 3rd party packages, they are pretty much unavoidable; a good example was the low level stream deprecation in FluentFtp a few months ago, just to name a prominent example.

    ObsoleteAttribute also has an overload, it's best practice to first throw a warning like mentioned in the article but before you remove the method completely, you do something like:

    [Obsolete("Foo is deprecated, please use Bar instead", true)]
public void Foo() => throw new NotSupportedException();

    Now that one will throw an error by the compiler instead of a warning.

    So yeah, you don't need to do the C# certification to be aware of the attribute, it's definitely not something uncommon like StructLayoutAttribute.

  • Shannon (unregistered) in reply to TheCPUWizard

    On a similar vein - if you'll permit me to get on my soap box and rant at web API vendors, it absolutely does not mean 'retire', 'sunset', 'shut-down', 'turn off', or 'disable'.

    Deprecation means it will still work -- but too often I've seen "we will deprecate this API on xx/xx/xx and it will no longer work". Arrgh. No, that's not what deprecation means...

  • (nodebb)

    I need to spend more time reading C# specs, given how often I use it these days. The last time I tried an [Obsolete], it was immediately treated as an error, so I couldn't do the graceful-deprecation thing. Presumably, I need to explore the particular compiler settings we're using to allow [Obsolete] to be used before we're done killing it.

  • richarson (unregistered) in reply to Mr. TA

    I vote this comment for comment of the month!

    (Or at least for the "Featured Comments")

  • Jonathan (unregistered)

    While this is absolutely a terrible change to allow into a C# code base, unless the person claimed to be anything more than a Junior in C#, I think it's a little unfair to say it's a total WTF, seems more like a case of someone just not yet knowing better yet.

  • (nodebb) in reply to PotatoEngineer

    The default constructor for ObsoleteAttribute has always been IsError=false (https://learn.microsoft.com/en-us/dotnet/api/system.obsoleteattribute.-ctor?view=net-8.0#system-obsoleteattribute-ctor).

    Maybe you are referring to the compiler setting -warnaserror to treat all warnings as errors, but in this case all warnings get treated as errors (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings) ?

  • TheCPUWizard (unregistered) in reply to Duke of New York

    @Duke - "As if anyone looks at compiler warnings. " -- I ensure (for environments that support it, such as .NET) that "Warnings as Errors" is set true, and have multiple layers to 99.999% enforce it (from git hooks, to PR checks, to official notice of violation subject to disciplinary action)...

  • (nodebb) in reply to Sauron

    As a bonus, renaming PopulateOfferNodes() to OBSOLETE_PopulateOfferNodes() means they had to replace every call.

    Unless the idea was to rename foo to OBSOLETE_foo and then create a new foo that calls OBSOLETE_foo for some time until it's replacement is ready. Not necessarily the best way, but no search and replace hunt is necessary then.

  • taco (unregistered)

    The real problem is that there is always a 'Marcus' who needs to 'deprecate' (as a sane developer, that word makes me recoil) perfectly functional software so he can keep re-inventing the wheel by 'restructuring', to justify his existence to his manager in the rat-race who looks at any downtime as a reason for 'obsoleting' Marcus, as the vultures we call shareholders demand more blood sacrifice each quarter. What, you made a billion in profit last quarter and that isn't enough? You need more? And you need even more the quarter after that? And even more, in the quarter after that?! How much is enough? When will you be satisfied? Nothing, and never?! Oh my god... This is the reason why, especially in large companies, there is no such thing as 'finished' software anymore. Sucks for everyone using the products, and the world at large, but what can we do? Fix capitalism? Hah.

  • GrammarNazi (unregistered) in reply to TheCPUWizard

    One of my pet peeves, "there".

  • (nodebb) in reply to Shannon

    On a similar vein - if you'll permit me to get on my soap box and rant at web API vendors, it absolutely does not mean 'retire', 'sunset', 'shut-down', 'turn off', or 'disable'.

    I mean, fair enough, but I just wish I could get people to stop writing "depreciate" instead.

Leave a comment on “An Obsolete Approach”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article