|
VectorX wrote: just appending
String concatenation?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
It's (almost) the right tool for this job.
|
|
|
|
|
I also found in several codes (written by some experts though) using string.Replace() to replace the text "{0} " with proper string values. Not only that, I found some code where they used:
string myStr2 = myStr1.ToString();
What is the significance of that code? Why do you need to ToString() a string?
If experts are doing like that, then what the freshers will do, who follows that expert who has several years of experience in that field!!!
Don't forget to Click on [Vote] and [Good Answer] on the posts that helped you.
Regards - Kunal Chowdhury | Software Developer | Chennai | India | My Blog | My Tweets | Silverlight Tutorial
|
|
|
|
|
string.Format is not a replacement for parameterized queries. You probably won't get SQL Injection with integer and date parameters, but as soon as you try to use Format / Replace for string variables, little Bobby Tables[^] comes along and ruins everything.
Also, DateTime.ToShortDateString depends on both the current culture and the user's regional settings. Changing either could break your query. If you're still stupid brave enough to use string.Format , at least make sure you're using a custom format string and the invariant culture!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
just looked into the code of an project made from a workmate.
may be he thought superman would fly in and delete the folder between the two if-clauses xD
if (System.IO.Directory.Exists(dest))
{
if (!System.IO.Directory.Exists(dest))
{
System.IO.Directory.CreateDirectory(dest);
}
fullDest = dest + fileInfo.Name;
}
|
|
|
|
|
Epic fail. Written at 4am by any chance ?
Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter.
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.
|
|
|
|
|
freakyit wrote: may be he thought superman would fly in and delete the folder between the two if-clauses
this could actually happen in a multi threaded environment
but then he would fly by again after the creation and delete it again =/
|
|
|
|
|
Looks like a classic example of code that originally did more than this. After the "more" was moved to somewhere else, this snippet was what was left behind. I've seen many examples and they always make the original programmer look really stupid. Have to admit - I've even done it myself
|
|
|
|
|
Shurely,
string IsSuperman() {
if (IsItABird())
return "Bird";
else if (IsItAPlane())
return "Plane";
else
return "Superman";
}
(Sorry - its a bad job, but someone's gotta do it.)
|
|
|
|
|
|
Did you just not READ the comment? He's concerned that the path separator is missing from the end of the dest variable. A not unreasonable concern. Your coworker knows about the System.IO namespace.. but apparently not the Path object. Path.Combine() is what he's in need of.
|
|
|
|
|
Path.Combine doesn't always work as one would wish
|
|
|
|
|
This leads me to once again point out how important that cup of coffee is before commencing to write any code.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
|
|
|
|
|
commited
|
|
|
|
|
Both the exists checks are unneeded. A manual would be more appropriate.
The FMSDN says:
If the directory already exists, this method does nothing.
|
|
|
|
|
we cant know! we cant judge.its windows afterall
d'Oh!
|
|
|
|
|
a fellow student told me of a strange code convention in his job:
almost every single method looks like this
{
try {
}
catch (...) {
}
}
directly after the head opens a try block over the whole body. all errors are just thrown away. the programs work and never crash!
they are world market leader
seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.
modified on Thursday, July 1, 2010 2:57 PM
|
|
|
|
|
Discarding errors is a great way to give the user the perception that all is right with the world.
|
|
|
|
|
RugbyLeague wrote: Discarding errors is a great way to give the user the perception that all is right with the world.
Old VB6 provided a more convenient means, though: "ON ERROR RESUME NEXT". Unfortunately, its lack of "Try"-style methods for many things(*) tended to make a more appropriate coding style painful.
(*) There are many places where one might want to do an operation which one expects might fail, and not worry if it does; e.g. one may want to create a table if it doesn't exist, but ignore it if it does. Checking for existence before creation won't completely solve the problem, since another client might create the table after the existence check. The nicest way would be to say "do command X, but don't worry if it fails." Unfortunately, the only convenient way to do that is with ON ERROR RESUME NEXT, a concept so ugly Microsoft defined a special statement just for it.
Incidentally, if a routine does an ON ERROR RESUME NEXT and then invokes another routine that fails but does not have an ON ERROR statement, that other routine will exit out to the routine which did the ON ERROR RESUME NEXT. Nasty, but not so horrible as ON ERROR RESUME, which would restart the entire statement in the parent routine, likely causing many statements in the called routine to be re-executed.
|
|
|
|
|
RugbyLeague wrote: a great way to give the user the perception that all is right with the world.
That's the goal, according to some of the teachers here.
If you find yourself in such a group, by all means, adapt or leave - you'll be the source of all bugs and errors if you try to move to structured error-handling
I are Troll
|
|
|
|
|
Eddy Vluggen wrote: you'll be the source of all bugs and errors if you try to move to structured error-handling Smile
Fair point.
Steve
|
|
|
|
|
Eddy Vluggen wrote: you'll be the source of all bugs and errors if you try to move to structured error-handling
so right^^ once turning on printing error messages to stderr, there was so much outpu - it was turned off immediately
|
|
|
|
|
Kevin Drzycimski wrote: directly after the head opens a try block over the whole body. all errors are just thrown away.
In Enterprise lingo, that's called the Try/Swallow pattern.
Jon Sagara
Some see the glass as half-empty, some see the glass as half-full. I see the glass as too big.
-- George Carlin
.NET Blog | Personal Blog | Articles
|
|
|
|
|
Jon Sagara wrote: Try/Swallow
I'm scared to reply to that one!
DaveIf this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier.
Please take your VB.NET out of our nice case sensitive forum.(Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
DaveyM69 wrote: Jon Sagara wrote:
Try/Swallow
I'm scared to reply to that one!
Dave
Promise, it won't swallow you, Dave.
|
|
|
|