|
In some point, two or three years ago, I discovered that coding as primary job is a dead end.
Then I switched to project management and scrum mastering.
Benefits:
1. Still working in "application development" and having contact with new technologies
2. Finally having time to code for fun (when and what I want!)
If you're sick of it - think about something else to do. It will not pass or get better. 
|
|
|
|
|
cmd.Parameters.Add("@SomeID", SqlDbType.Int)
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()
It appears this developer didn't have a strong conception of data types, knowledge of AddWithValue, or knowledge that the "@" is optional when specifying parameters. 
|
|
|
|
|
AspDotNetDev wrote: SqlDbType.Int
Soooo many practitioners think that's necessary. 
AspDotNetDev wrote: AddWithValue
I never use that; it's not defined by an Interface I use. I use IDbCommand.CreateParameter and IDataParameterCollection.Add.
AspDotNetDev wrote: is optional
That may be true with the database system you use; it may not be true with all the database systems I use.
|
|
|
|
|
I also prefer to see it, even if optional because it makes it more obvious that it is a required parameter.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
|
|
|
|
|
PIEBALDconsult wrote: Soooo many practitioners think that's necessary
I find nothing wrong with specifying that. The thing I find funny is the specification that it's an int, and then on the next line passing in a string, which was actually an int to start with (rather than casting to an int).
PIEBALDconsult wrote: I never use that
The first thing I did was convert it to LINQ. Now the call looks a bit like context.SomeStoredProcedure(someInt). In my next project, that's basically still how I'll do it, only I'll be abstracting away the data source and using Ninject, so where it's actually used it'll look more like dataStore.DoSomething(someInt).
PIEBALDconsult wrote: That may be true with the database system you use; it may not be true with all the database systems I use
I can't seem to find any documentation regarding the "@" being optional, but much of my code has been written with this fact in mind. SqlClient.SqlCommand knows to automatically prefix "@" for parameter names. I did come across this (see "Working with Parameter Placeholders"), which indicates the parameter naming varies per client. I wonder, then, if removing the prefix and letting the query composer do the prefixing is the best way for the code to be cross-client compatible.
|
|
|
|
|
AspDotNetDev wrote: I can't seem to find any documentation regarding the "@" being optional, but
much of my code has been written with this fact in mind. SqlClient.SqlCommand
knows to automatically prefix "@" for parameter names. I did come across this (see
"Working with Parameter Placeholders"), which indicates the parameter naming
varies per client. I wonder, then, if removing the prefix and letting the query
composer do the prefixing is the best way for the code to be cross-client
compatible.
That's an interesting point.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
I don't think there's a real way to achieve portability on that, it strongly depends on the connector used. ODBC for example uses a positional syntax for parameters, ignores parameter names and uses the '?' char as a parameter placeholder. MS-Access, same thing. The MySQL provider IIRC can be configured both ways, but by default requires the '@' char (or maybe the reverse, it has been a few years since I last used it).
Luca
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása
|
|
|
|
|
AddWithValue is the best thing since sliced bread (except for bacon)... Makes everything a hell of a lot easier. 
Why can't I be applicable like John? - Me, April 2011
-----
Beidh ceol, caint agus craic againn - Seán Bán Breathnach
-----
Da mihi sis crustum Etruscum cum omnibus in eo!
-----
Just because a thing is new don’t mean that it’s better - Will Rogers, September 4, 1932
|
|
|
|
|
I quit using AddWithValue when I discovered it eliminated the query optimizer's ability to generate efficient queries. With Stored Procedures it's probably ok, but if the query is embedded in your code it's a performance killer.
|
|
|
|
|
Easier isn't always better.
|
|
|
|
|
AddWithValue can cause problems where conversions may not be as expected: better to use Add and be explicit about what you are doing. And what harm the @? Just because something is optional doesn't mean you shouldn't use it - verbosity is king - it promotes clarity.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Notice anything else about why the code is strange?
|
|
|
|
|
Yes indeed, but I didn't think that was your point.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
My only point is to make fun of as many things as is possible in that code snippet. However, the only real thing wrong with it is converting an integer to a string and then using that string as the value of a parameter that was just explicitly specified to be an integer.
|
|
|
|
|
Indeed - but you missed the smiley! I took you seriously! I wouldn't do it in that way (even with correct typing), in any case - too clumsy and not reusable. 
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
AspDotNetDev wrote: "@" is optional when specifying parameters.
Actually I believe the "@" symbol only became optional in .Net Framework 2.0 and above, before that it was a requirement. Please don't take my word for that, but its coming from a rusty memory of my own personal experience.
|
|
|
|
|
Well, in the codebase I handle I'm enforcing a standard of explicitly stating the parameter type when using ADO.net. Granted, we're autogenerating the DAL using an internal tool, but it helps in a lot of situations. Example: when using a string field, if you specify the length, ADO.net will truncate the parameter to the expected maximum length. Otherwise it gets passed to the underlying db and the query will error out. For us, the former behaviour is preferred. YMMV
Luca
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása
|
|
|
|
|
I believe this line:
cmd.Parameters("@SomeID").Value = Session("SomeID").ToString()
Should be this:
cmd.Parameters("@SomeID").Value = Int32.Parse(Session("SomeID").ToString())
|
|
|
|
|
The best thing I ever saw while debugging code was comments in Polish. The variables were also given Polish names so discerning the possible usage was more difficult. I asked a Polish programmer to please translate the comments and he told me there was not an English translation possible. I've always thought that was funny. To this day, in the code, when someone wants to use the buffer class they construct a CBoffo, usually called Boffo. It always reminds me of Hans and Franz doing a SNL skit.
|
|
|
|
|
We outsourced the programming of an application to a pole (or whatever people from poland are called) contractor once. What did we get? The whole program written in polish, even the documentation was in polish.
|
|
|
|
|
That is pretty funny . Have you outsourced anything since then?
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
SoMad wrote: Have you outsourced anything since then?
Nope. We are now writing the code in english on-site. And we still try to retranslate the polish code back to english.
|
|
|
|
|
|
SoMad wrote: Sorry, I feel bad for you guys.
No need to do so. We just hired another polish dev to write the code for updates of the app until we fully translated the source.
|
|
|
|
|
You did what!!! Hmmm...I think I need some time to figure out if that is a brilliant move or if it is the mother of bad decisions 
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
