|
And that wasn't listed as a breaking change. Wow, M$, you seriously f***** that one up.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Message Closed
modified 21-Nov-20 21:01pm.
|
|
|
|
|
You are right. But I want to make the programs fool-proof when they are intended for my own use: I know my tyipng bheavior.
|
|
|
|
|
Tip; turn of your spellchecker.
I've seen more errors in recent "spell checked" documents than in old unchecked versions. I think that the spellcheckers are causing them, instead of preventing.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Or the Autocowreck (AKA Autoincorrect)
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
I agree and don't.
Input-validation is a nice thing, if it is generated; especially cool for banknumbers and social security-numbers, things where I tend to make mistakes. Most of the validations CAN be generated, so why aren't they?
It is not something that one should blindly spend money on; in that case it will simply cost money, often without knowing the return-on-investment of the effort - how many errors did it actually prevent, and at what cost?
No, it is more valuable to invest time and think about what errors you want to prevent. One of the things often omitted is the check for duplicate records - many places use identity-fields simply to not have to worry about a primary key-field.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Looking at the comments[^], the change was made to avoid "a transient 'no error' state". 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's a good point. Their reason is totally valid. But their solution is NOT.
When an error has to be replaced by a different error, the system is in an invalid state when only one of the two steps of adding the new error and removing the old error has been completed. Two errors on the field are as wrong as no error on it. It's similar to transferring money from one bank account to another bank account: do not create or loose money by omitting one step. A solution could be a transaction.
But I think the simplest solution here is similar to a PropertyChanged event. Get rid of the Added/Removed enum, and take two error properties: OldError and NewError.
When you leave the valid state, NewError contains the error which is now communicated with Added, and OldError is null.
When an error gets replaced by a different error, NewError contains the freshly incurred error (now with Added), and OldError the previously encountered error (now with Removed).
When you return to a valid state, NewError is null, and OldError the previously encountered error (now with Removed).
That's a better solution, isn't it?
|
|
|
|
|
That would be a better solution. Now you just need to convince Microsoft to adopt it! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
How many compiler errors, potential NullReferenceExceptions, StackOverflowExceptions and whatnot can you spot in this presumably review-ready class?
And the million dollar question: Can you guess the intended purpose?
public class QueryContainer
{
private static List<QueryContainer> Container;
private static QueryContainer instance;
public static QueryContainer Instance
{
get
{
if (Instance == null)
instance = new QueryContainer();
return instance;
}
}
public int _searchID;
public int ID { get { return _id; } }
public string Query
{
get { return Container.Find(instance => instance._id == _searchID).Query; }
set { Container.Query = value; _id =+ 1; }
}
private int _id;
private string _query;
private QueryContainer()
{ }
}
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Threading issues certainly.
What language?
|
|
|
|
|
My main guess is C#
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
PIEBALDconsult wrote: Threading issues certainly.
You're WAY off  (See my solution-post below)
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
How did that person even think that this was ready?
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
It may cause NullPointException :
return Container.Find(instance => instance._id == _searchID)
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
|
|
|
|
|
Singleton! 
- Compiler error at
=+ - Threading issues: susceptible to multiple instances being created
- Possibly a StackOverflowException while "get"ing the Query
- Possibly a NullReferenceException while "get"ing the Query
- Possibly a NullReferenceException while "set"ing the Query
- Should have a static constructor
Sascha Lefèvre wrote: Can you guess the intended purpose?
Write a test-friendly class? 
You have just been Sharapova'd.
|
|
|
|
|
Agent__007 wrote: Compiler error at =+
Really? That part of the code compiles for me.
It doesn't do what the author probably intended, but it compiles.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Singleton is not thread-safe, Query property is potentially recursive, and can cause null exception. Also shouldn't query container contain list of Query instead of list of QueryContainer if QueryContainer is supposed to be a singleton (i.e. having only one). Also the whole class is crazy. Why have ID counter if you're using kinda "singleton"? Also no comments on what the class does or on public members. This IS Sparta! 
|
|
|
|
|
Singleton is usually one of the first design patterns people learn. They immediately fall in love with it and are become blind for any other patterns out there.
I'd say the problem with this code would be that it causes brain damage.
|
|
|
|
|
I assume the intended purpose was to create a list of recently used queries. Even though the list was never actually filled (or allocated for that matter).
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Your warnings obviously weren't dire enough - he's back[^], with a modified version of the same class, which still doesn't fix his original problem. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Clue bat needed in Aisle 5! Clue bat needed in Aisle 5!
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Yes, I saw it.. sighed, and decided to let someone else answer since he apparently didn't believe me 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Among all the toe-curling flaws in there, these are my two favorites:
It's not even a singleton - it's a "noneton": Trying to access the Instance-property will cause a stack overflow due to recursion..
The List<QueryContainer> will be really, really short. Even when fixing the above flaw..
And the answer to the million dollar question:
It's supposed to somehow (don't ask me) help with fixing code that is vulnerable to SQL-injection.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
