A programming question!
-
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.[Incomplete] [LitelyTested] [CutAndPasteAtYourOwnRisk] [CodeProjectQAQuality] [hmmmmNotSureAboutThis] [YouFeelLucky]
The less you need, the more you have. JaxCoder.com
-
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better. -
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.How about a SinisterHackAttribute for makeshift code that still needs attention? Don't beat around the bush and use a name that says exactly what's going on. And you might also need the TheBossWillKillYouIfYouMessWithThisCodeAttribute.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.I'm going to be the heretic here, and claim the "kludgey" code should not be in the public repository of your library. It should either work properly, or be kept in your private repository until it can be fixed. To give examples from other engineering fields, would you tolerate a building code which deems it acceptable that a building will collapse approximately 1 in a million times that you lock the front door? would you tolerate electronics that burst into flame approximately 1 in a billion times you switch them on? So why should your clients be expected to tolerate "kludgey" code?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
[Incomplete] [LitelyTested] [CutAndPasteAtYourOwnRisk] [CodeProjectQAQuality] [hmmmmNotSureAboutThis] [YouFeelLucky]
The less you need, the more you have. JaxCoder.com
You forgot some important things. [DontTouchOrTheBossWillRipYourHeadOff] [UnmaintainableButLightningFast] or simply [ThisIsDeliberate]
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.MarkedForImprovement ToBeReworked NotFinalYet FutureOptimization IncomingChanges ...
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Could work if they allowed deriving from
ObsoleteAttribute. But. They. Don't. :mad: -
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.Consider
#warning This code is dodgy, I was sober when I wrote it
public void Kludge()
{
// sober code goes here
}Warning in your output every time you build
veni bibi saltavi
-
Consider
#warning This code is dodgy, I was sober when I wrote it
public void Kludge()
{
// sober code goes here
}Warning in your output every time you build
veni bibi saltavi
So, an OutOfGinAtribute()
Wrong is evil and must be defeated. - Jeff Ello
-
[Incomplete] [LitelyTested] [CutAndPasteAtYourOwnRisk] [CodeProjectQAQuality] [hmmmmNotSureAboutThis] [YouFeelLucky]
The less you need, the more you have. JaxCoder.com
Mike Hankey wrote:
[CodeProjectQAQuality]
Surely, nobody here produces SUCH bad code? :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain -
I'm going to be the heretic here, and claim the "kludgey" code should not be in the public repository of your library. It should either work properly, or be kept in your private repository until it can be fixed. To give examples from other engineering fields, would you tolerate a building code which deems it acceptable that a building will collapse approximately 1 in a million times that you lock the front door? would you tolerate electronics that burst into flame approximately 1 in a billion times you switch them on? So why should your clients be expected to tolerate "kludgey" code?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
would you tolerate electronics that burst into flame approximately 1 in a billion times you switch them on
Might not be the best example because it seems like we do: ‘The irony’s not lost on me’: Solar panel safety device led to 500 per cent rise in rooftop fires[^]
-
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.PIEBALDconsult wrote:
not-yet-ready-for-primetime
Seems to be a natural state for all the code in the world. The opposite
ReadyForPrimetimeAttributeor justWorkingAttributebelongs to science fiction. -
Consider
#warning This code is dodgy, I was sober when I wrote it
public void Kludge()
{
// sober code goes here
}Warning in your output every time you build
veni bibi saltavi
Even when it is referred to by other code?
-
You forgot some important things. [DontTouchOrTheBossWillRipYourHeadOff] [UnmaintainableButLightningFast] or simply [ThisIsDeliberate]
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.PIEBALDconsult wrote:
But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it.
OMG. No. Is there ever any code you don't intend to rework? Over time my code would evolve into endless warnings every time I compiled it. Until I turn it off, making it completely pointless.
-
PIEBALDconsult wrote:
But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it.
OMG. No. Is there ever any code you don't intend to rework? Over time my code would evolve into endless warnings every time I compiled it. Until I turn it off, making it completely pointless.
Sure, yet some are worse than others, or at least some times I know what I want to do when I have the time.
-
(I broach this subject here because I don't think there's an answer. Note the "rant" icon.) Consider:
ObsoleteAttribute -- Marks the program elements that are no longer in use.What would be the opposite/complement? A way to mark some code as not-yet-ready-for-primetime? Not to the extent of throwing aNotImplementedException, because the code exists and works (mostly). Not atodoeither; that's too passive. But, if I have a kludgey Method I intend to rework at some convenient future time, I want to be reminded about it every time I compile code which calls it. Even if the Method has been compiled into a DLL. AnObsoleteAttributewill do this -- but I expect that it would be confusing to my colleagues. Even aUseAtYourOwnRiskAttributewould be better.I use
#warningdirectives in my C# for this. Their messages show in every compile including product builds, so I can't forget things that need to be reviewed. It's nagging without being obstructive.Software Zen:
delete this; -
I use
#warningdirectives in my C# for this. Their messages show in every compile including product builds, so I can't forget things that need to be reviewed. It's nagging without being obstructive.Software Zen:
delete this;Even when referencing something in a DLL?
-
Even when referencing something in a DLL?
For developing at my desk, the warning message is only issued when compiling the DLL, obviously. Our automated build process builds all parts of the product from source which causes the warnings to be in the build log. Both results are sufficient to help me keep track of items for later changes. The exceptions to both of these cases are third-party libraries supplied without source code. We use several of those to control hardware we buy off-the-shelf.
Software Zen:
delete this;