|
Here in Florida I have Spectrum service. On an Ethernet connection (not WiFi) I get 496 MB/s. That is more than we need.
Get me coffee and no one gets hurt!
|
|
|
|
|
Wow. I wonder if my Palm Beach client knows about that. That's amazing.
Real programmers use butterflies
|
|
|
|
|
I forgot to mention: That is the download speed. The upload speed is less than 30MB/s.
Get me coffee and no one gets hurt!
|
|
|
|
|
honey the codewitch wrote: plugged it into a wire today
That's probably the best decision some people could have made in a long, long time.
As much as I hate getting tangled in wires, I hate wireless. With a passion.
|
|
|
|
|
(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 a NotImplementedException , because the code exists and works (mostly).
Not a todo either; 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.
An ObsoleteAttribute will do this -- but I expect that it would be confusing to my colleagues.
Even a UseAtYourOwnRiskAttribute would be better.
|
|
|
|
|
PIEBALDconsult wrote: A way to mark some code as not-yet-ready-for-primetime?
[UnderDevelopment]
[Future]
[ComingSoon]
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.
[Sh*ttyCodeAhead] (self-sensored that, lol)
[KludgeyCode]
|
|
|
|
|
Marc Clifton wrote: [UnderDevelopment]
[Future]
[ComingSoon]
[BetaQuality], and presumably [AlphaQuality].
Not a .Net developer, but it looks like you can create your own Attributes: Writing Custom Attributes | Microsoft Docs, so maybe actually doable?
Keep Calm and Carry On
|
|
|
|
|
Could work if they allowed deriving from ObsoleteAttribute . But. They. Don't.
|
|
|
|
|
For probably good reason. [^]
Also that article is a solid introduction
|
|
|
|
|
Idea:
what about a Custom Codeanalyser NuGet-Packet, witch contains the Attributes and does the Messages for them.
but might be a little overkill
|
|
|
|
|
[Incomplete]
[LitelyTested]
[CutAndPasteAtYourOwnRisk]
[CodeProjectQAQuality]
[hmmmmNotSureAboutThis]
[YouFeelLucky]
|
|
|
|
|
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.
|
|
|
|
|
Here there (may) be dragons.
|
|
|
|
|
Mike Hankey wrote: [CodeProjectQAQuality] Surely, nobody here produces SUCH bad code?
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
|
|
|
|
|
#define, #if and some imagination.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Consider
#warning This code is dodgy, I was sober when I wrote it
public void Kludge()
{
}
Warning in your output every time you build
veni bibi saltavi
|
|
|
|
|
So, an OutOfGinAtribute()
|
|
|
|
|
Even when it is referred to by other code?
|
|
|
|
|
PIEBALDconsult wrote: not-yet-ready-for-primetime
Seems to be a natural state for all the code in the world. The opposite ReadyForPrimetimeAttribute or just WorkingAttribute belongs to science fiction.
|
|
|
|
|
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.
|
|
|
|