Curse is a plugin which helps you to cleanup bad programming habits with ease!
Every time you open Studio you will receive a popup with a bad programming habit you must not break for the rest of the Studio session, hence the name Curse!
It’s relatively self explanatory, and you can find it here:
Scared to use this as it will curse me like 10000000000 times 
Anyway, good plugin! Hopefully will make newer programmers adapt to better programming habits!
Does this look through what you are doing? I can see that being very helpful to ensure it is specific as to the curses appearing.
No, but it’s definitely a cool idea. You’d have to make some sort of AI to check whether one of the practices is not being followed - otherwise it wouldn’t check for the specifics / context of the code.
But, seeing as I don’t follow my own rules, I don’t have the motivation to do that 
You could make your own!
I may try soon! I’ve never really been in the plugin game before.
What are all the things it looks for?
Kind of spoils the excitement but if you must:
curses = {
“Directly referencing children (Part.Child or Part[‘Child’])\nThis will error if this instance doesn’t exist, completely breaking your whole script.\nIt’s better to use WaitForChild or FindFirstChild in most cases!”,
“while wait() do end or repeat wait() until …\nThis will check infinitely until a statement is true. Isn’t it better just to run once once the statement is declared to be true? You can do this with Event:Wait()!”,
“wait()\nUsing wait() without a substantial value inside the brackets is almost never beneficial - wait() is very unreliable and waits for 1/30th of a second, you’re better off using game:GetService(‘RunService’).Heartbeat:Wait() (1/60th of a second)!”,
“if 1== 1 then end\nMake sure your code is spaced out correctly otherwise it looks unreadable! Let me fix it for you: if 1 == 1 then end”,
“Global variables inside functions\nInside a function, you should never set a global variable. This can be accessed in the rest of the code, meaning it could break it, and it also underlines it with an annoying blue line. Use ‘local var = …’ to set a local variable!”,
“Not adding comments\nYou should always comment sections of code so you understand what they do. This is especially true if you’re making a game with other people!\nYou can use the symbols ‘–’ to create a comment (like --Comment here).”,
“Bad variable names\nVariable names should be so good you can tell what the code does just by looking at them!\nAlways make sure your variable names are at least 8 characters (or a word) long, like ‘IterationNumber’ or ‘tween_object’.”,
“Deprecated strategies\nThese are dangerous because they could be removed at any time! Instead of using something like Instance:Remove(), use Instance:Destroy() or Instance.Parent = nil”,
“Deprecated case\nNever use event:connect() again!\nUse event:Connect() instead!”,
“Using free model scripts without understanding how they work\nFree models are great because they’re free, easy, and powerful. However, if you don’t understand how they work you’re not helping yourself and could even be injecting a virus into your own game!”,
“Programming for over 3 hours straight\nNever program for too long, or you’ll get burnout. Take a break for the rest of the day, maybe play a game or go outside!”,
“Programming alone\nProgramming all alone is building a staircase into insanity. Make sure you interact with other humans once in a while!”,
“Not having enough water\nHave you drunk water in the last two hours?\nIf not, go and drink some now.”,
“Using spawn over coroutine.wrap()\nSpawn is much easier than coroutine.wrap() but it has a built in wait() at the start of the code making it less useful!\nIf you don’t know how coroutines work, look them up!”,
“Using API’s without a pcall()\nServices like text filtering, datastores and HTTP requests can all fail randomly. You should always wrap them in a pcall and repeat until the code completes successfully!”,
“Directly referencing services like game.Players\nIf the name of game.Players is changed, it will break the code! Use game:GetService(‘Players’) instead.”,
“Using Gui’s without IgnoreGuiInset\nMost of the time, you will want this property to be true. If you’re using something like an ambient effect or a blood on screen Gui, without this property there will be an annoying line at the top of the screen ruining immersion!”,
“Using multi line comments without ‘–[[]]’\nIf you span a comment over multiple lines, you can use --[[ comment here ]] to avoid having to write ‘–’ over and over again!”
}
Good idea but the UI is so bad man. maybe change the font color to white at least
A simple parser does the job! AI is just a bunch of if statements 
For things like :connect you could even do if (script.Souce:find(":connect") although if the person had a module script with that function it’d falsely flag it.
:FindFirstChild and :WaitForChild are much slower than just using .
If a Instance is parented to nil but is still referenced it wont get garbage collected, this could cause memory leaks in some cases.
Overal the advice seems quite good. But there are a few I disagree with.
What if I perform the bad habit?
A team of robots is dispatched to destroy your PC.
@OP
I think this is a fun idea, it would be even cooler if it did some sort of parsing to find bad habits. There are lua-in-lua parsers available that turn lua code into data you can actually work with and find context and things, but, its definitely advanced.
I’ve done a few things before but it may be more effort than its worth, which is unfortunate
I think its cool! But I would say that you can make themes, and a on off setting, because I don’t really want to be cursed everytime I open studio, since I am not using pcall, for example
Lmao, I love this, I will maybe use this since I still have a bunch of bad habits from my earlier days of scripting
I like this. But make sure the advice is entirely sound, in your photo example you say to always repeat the call… This isn’t always the best solution, things like text filtering already implement their own retry logic, at most you’d just need a pcall and that’s it. Plus sometimes you don’t want to be repeating HTTP requests.
So as long as the curses are sound I think this will be very nice 
Using :WaitForChild makes sure you don’t just call nil which will break your game.
If it’s possible to break so that a pcall is needed, you may as well repeat until it works. Especially if it’s something important that needs to work.
^ this, even if you make a mistake it still warns you after 5 seconds that it could yield forever.
maybe 
If it’s possible to break so that a pcall is needed, you may as well repeat until it works
I did not say never repeat, I just said it’s conditional and that giving the advice to always repeat is just not right. I mentioned because some internal API’s like text service’s FilterStringAsync have their own retry logic. Even the api hub advises against doing retry for it:
In essence i’m just saying don’t give any advice that isn’t going to be correct in every common usage.
Thanks for this information - I didn’t know this myself!
I’ve updated the plugin to be up to date
Please add more interesting curses! This has provided a why this is bad instead of just out right saying it’s bad and what a solution can be! Thank you 
