If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.
Shitlist Driven Development (2016)
41–50 of 148 posts
Re: Shitlist Driven Development (2016)
#42If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.
This is literally one of the topics covered in the article and the author advocates for the same solution, documenting the alternative in the error/deprecation message...
Re: Shitlist Driven Development (2016)
#43Earlier quoted context omitted.
This is literally one of the topics covered in the article and the author advocates for the same solution, documenting the alternative in the error/deprecation message...
Is supporting the article's position frowned upon?
Re: Shitlist Driven Development (2016)
#44Earlier quoted context omitted.
... windows ? MacOS ? Literally every Adobe software ? Literally every large audio / video / 3d création software ? Every large game engine ? I don't know, I notice pretty much the opposite in the field of software I know - smaller software come and go, but the large ones were there 20 years ago and will likely still be there in twenty years
So you'd write a new application using win32? There is a lot of inertia driving maintenance on some of these large products but there is also a ton of deprecation taking place internally relative to them.
Re: Shitlist Driven Development (2016)
#45I will probably remember Sirupsen forever for his move of breaking Golang projects by renaming his github username. This led to go modules freaking out because different project used different name casing for the dependency. He has a popular logging library and go modules are angry when you rename github usernames..
Or is this an "unofficial but popular" library?
Re: Shitlist Driven Development (2016)
#46Here, a “shitlist” tracks existing uses of deprecated behavior within a large code base. It prevents new uses of deprecated behavior without disrupting legacy code. This is a temporary measure used to facilitate refactoring large code bases.
Re: Shitlist Driven Development (2016)
#47I will probably remember Sirupsen forever for his move of breaking Golang projects by renaming his github username. This led to go modules freaking out because different project used different name casing for the dependency. He has a popular logging library and go modules are angry when you rename github usernames..
Does go-lang not have "official" repos, including clones of popular repos, to avoid deps on personal repos? Or is this an "unofficial but popular" library?
Re: Shitlist Driven Development (2016)
#48I'm more curious about how things like shitlists are implemented in different languages. Most of my experience is C#, where calling deprecated code triggers a warning. Considering that C# warnings will fail in CI, how would someone do a C# shitlist? Would it require some kind of #pragma, that would stick out like a sore thumb in a code review
Re: Shitlist Driven Development (2016)
#49If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.
Deprecated means “still supported but its use is discouraged.” It does not mean “no longer supported.”