4 ms·
Wait, some code really does suck. The difficulty here is that "sucks" is a "catch all" that can include a lot of types of flaws. These might be flexibility, err
by Quarrelsome 16y ago
Wait, some code really does suck. The difficulty here is that "sucks" is a "catch all" that can include a lot of types of flaws. These might be flexibility, error-proneness, security, performance or maintainability/confusion.
In some cases the suckiness is an appreciated trade-off against time-taken and is bearable in maintenance. If this is the case we should try to be more diplomatic about the problems when assessing the code.
However, some code does suck. There is a certain type of easily preventable badness that slowly manifests itself in a project that isn't being effectively maintained.
Case in point in my current world of "joy":
public class MainForm
{
public static Form FormInstance;
public MainForm()
{
FormInstance = this;
}
}
If you're wondering, there are over 200 references in the code to MainForm.FormInstance.
- mcherm 16y agoIf your goal was to prove that some code unambiguously "sucks", then your example works against you. Because as I read this I see what may be a perfectly reasonable solution to common problem. (For future-proofing, the developer wanted to be sure most of the code shared a single INSTANCE rather than a CLASS with all-static methods. Then later, multiple instances could be used if needed. But since for now only one is used, she took the quickest and easiest approach to instantiating that single instance: no need for fancy factory classes when the instantiation will only be done once!)
- hnal943 16y agoThis is a failed attempt at a singleton pattern. The main problem here (there are MANY) is that there is no check to see if a Singleton already exists, meaning that the "Singleton" can be scrapped and replaced with a new object (most likely by accident) at any time. This code does in fact suck unambiguously.