|
I agree with you. Just to add on, it's first 30 lines and not the end of whole code. It was just based on first textbox value, similar if for other following textbox was suggested.
Complete answer says: if TextBox3 text can change then it now consider TextBox3 values..
It's too many code lines!
|
|
|
|
|
BobJanova wrote: 30 lines where 5 would do is a problem
Well I wouldn't write it that way, but I don't consider it a problem (certainly a smell though) and wouldn't necessarily change it if it works properly -- it ain't broke, there's probably more important things to do than to clean this up.
However, the OP says that this is just one small example, so perhaps revisiting all of it is worthwhile in this case.
|
|
|
|
|
Sandeep Mewara wrote: bellow method can help
It helps me...
bel·low/ˈbelō/
Verb: (of a person or animal) Emit a deep loud roar, typically in pain or anger: "he bellowed in agony";
It was broke, so I fixed it.
|
|
|
|
|
Using a control array might be better here - you could then loop through your checks and would also benefit from using the same event handler for all elements of the array rather than 12 seperate ones.
|
|
|
|
|
I hope this counts as a subtle bug and can help those encountering something similar.
I'm reading in a bunch of data from files. Basically a datetime (dts) and a float value. Because we're talking about 1.3 million records which I read in with several files, create a list of insert queries and execute them by 100 at the time. Everything worked except for some batches.
So looking at the errors, it says it runs into a unique constraint (dts is unique). Fine, what value was double then? none.
 is my state of mind by now. So I continue looking and print out the failed batches and sure enough there are double values in there. Checking the corresponding files : no doubles. But what does my little eye spy? double dts values start with 3 'o clock and only at the end of march! Daylightsaving (DTS).
The bug: I use java's GregorianCalendar and if you don't specify the timezone it will convert the 2:00 until 3:00 to 1 hour +. so 2:30 becomes 3:30 etc... What is strange though, is that there is no warning, no exceptions nothing. Just implicit conversion.
Perhaps it is my misunderstanding of the object, but if you encounter something similar, you just might want to check in this direction.
PS: I considered this forum to be the replacement of subtle bugs.
[EDIT]
The solution is to set the timezone to UTC.
If you use de SimpleDateFormat class to format the dates to string. This also has a timezome, which you also need to set to UTC to avoid having the date converted.
[/EDIT]
V.
modified 11-Jul-12 2:45am.
|
|
|
|
|
That is a known issue with Java, and Sun (and Oracle) have stated it won't be fixed because "it might break existing programs."
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions.
Dave Barry
Read more at BrainyQuote[ ^]
|
|
|
|
|
To be fair, it's not just Java's problem. Once a year, any language/environment/framework/program that uses local time with daylight saving is going to have time ambiguity for an hour and once a year it'll have a nonexistent hour.
Using UTC makes a lot of sense.
 Now, if only they'd address the leap second problem...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Yes, well this might also become a problem soon... 
One of the imports is per millisecond...
V.
|
|
|
|
|
Zac Greve wrote: That is a known issue with Java, and Sun (and Oracle) have stated it won't be
fixed because "it might break existing programs."
Exactly where is that stated?
|
|
|
|
|
V. wrote: Dating
And there was me hoping to find a match. 
Signature construction in progress. Sorry for the inconvenience.
|
|
|
|
|
On CodeProject? I don't think so 
|
|
|
|
|
|
I can't believe it took 4 posts before someone said something. 
Membrane.Inside("Insane");
|
|
|
|
|
V. wrote: What is strange though, is that there is no warning, no exceptions nothing. Just
implicit conversion.
So now is the time to get the following idea into your head...
Timestamps ALWAYS have an associated timezone.
If it isn't explicit then it is implicit.
So anytime you see a timestamp value you MUST determine how the timezone will be determined. Always.
And this has nothing to do with Java. It is true for any programming language and for that matter other types of usage as well.
V. wrote: So looking at the errors, it says it runs into a unique constraint (dts is
unique). Fine, what value was double then?
And there are other things about timestamps as well...
The resolution for timestamps is not absolute. Especially across boundaries. One example of that is that the MS SQL Server datetime resolution for milli-seconds is less than that of windows. So you can put a value into SQL Server and get it out with a different millisecond value.
Because it isn't absolute relying on it to be unique without quaranteeing the coarseness to be more than a second is probably asking for trouble.
And for Java the resolution of java.sql.Timestamp as represented by the base class java.util.Date is SECONDS, rather than nanoseconds as represented by java.util.Date itself. Read the docs on java.sql.Timestamp for specifics.
|
|
|
|
|
... when you start to code like this
var splittedKey = Key_.Split(new Char[]{'.'});
(yes|no|maybe)*
|
|
|
|
|
I like. I like very much!
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
That gave me a chuckle I really needed.
|
|
|
|
|
Place it randomly in your code... 
(yes|no|maybe)*
|
|
|
|
|
Oh, I have to copy this some day 
Soren Madsen
|
|
|
|
|
This is SO much going into my code, one way or another... Epic win!
|
|
|
|
|
Just found this little gem in a live application that has been wrote (for us) and maintained by an outsourcing partner we use...
paraphrased to make it easier to read.
string keyToFind = "asdfgsd44rtgr";
Dictionary<string, object> dctTemp = GetDictionary();
object theObject = dctTemp.ToList().FirstOrDefault(x => x.key == keyToFind).Value;
This is in a live piece of code, and is run on every application login.
As far as I'm aware, the compiler would not be able to optimise this to use dctTemp[keyToFind] and therefore would not be using a HashCode
|
|
|
|
|
This is "wise foresight": In the next update, they can say that they increased their performance by about 20%.
I've the feeling, some companies introduce bugs on purpose in their own application to boost the sale for their future updates.
If you find spelling- or grammer-mistakes, please let me know, so that I can correct them (at least for me) - english is not my first language...
|
|
|
|
|
|
Martin Thwaites wrote: run on every application login
So, how often is this?
Unless there are a lot of logins/second, don't sweat the small stuff.
IMO, the use of ToList (which can simply be deleted) and FirstOrDefault is less of an issue than the fact that they're storing objects. That's a bigger WFT than the optimization from the dictionary specific methods.
Don't optimize for speed until you have confirmation it's a hotspot.
Optimize first for robustness and maintainability.
And be aware, it can't be replaced it with:
object theObject = dctTemp[keyToFind];
For the same behavior, it'd have to be:
object theObject = dctTemp.ContainsKey(keyToFind) : dctTemp[keyToFind] : null;
|
|
|
|
|
I wasn't saying it was a hotspot, just that it's poor use of code. It's actually nowhere near to being a hotspot (they have 1 particular click in the application that takes 15 minutes to load the page, and therefore only works when there is a decent internet connection and a high timeout set!).
The object thing is FAR worse, however, in the context of how they've wrote the application it does make sense. That is actually one of the things I'm tackling at the moment.
This is one of many issues I've found that they've put in (before I started reviewing the code), and I suspect that they will be doing less now.
I also appreciate it can't be replaced by exactly what I've said based on the code sample, and in the application itself it would actually need to be different than you've suggested.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
