|
I'm guessing he was a dual major - CS / Philosophy - and was attempting to express existentialist nihilism through code.
|
|
|
|
|
AFAIK, he ended up switching to the hardware aspect of computing and has done much better.
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???
|
|
|
|
|
You clearly need to write some unit tests for your unit test
|
|
|
|
|
The project I'm currently working on has been developed by four people, including myself, over the course of the past two years. While looking through some code yesterday, I saw many instances like this:
var someInt = model.SomeIntProperty;
SomeMethod(param1, param2, someInt != null && someInt.HasValue ? someInt.Value : (int?)null);
Why? Is that really necessary, to check the value, pass the Value if it has one, and otherwise pass 'null' cast as a nullable int?
This project also utilizes Entity Framework for the data access layer. The same contractor (contract was not renewed, for several obvious reasons) also wrote some data access code at one point. No, he didn't use EF with LINQ - he called "context.Database.ExecuteSqlQuery" methods, using const string variables for the queries. The majority of them are pretty basic select statements.
private const string SomeSqlQuery = "select * from table1 where field1 = {0} and field2 = {1}";
var field1 = model.SomeField;
var field2 = model.SomeOtherField;
context.Database.ExecuteSqlQuery<SomeType>(SomeSqlQuery, field1, field2);
The problem? We discovered, by chance that the "format string" construct for the SQL query is supported - until SQL Server 2008 R2. If the target DB is ever upgraded from SQL Server '08 to '08 R2, this application would not work in several cases. We had to convert all of these so that they take "@field1" type parameters, and then pass SqlParameter objects to the ExecuteSqlQuery methods. But I don't understand why he didn't use EF with LINQ queries, as the rest of the data access code does?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Matt U. wrote: someInt != null && someInt.HasValue ? someInt.Value : (int?)null Well, that's pretty clear: those guys feared a NullReferenceException when someInt was null and they call someInt.HasValue ...
Why would they assume a magician added by the compiler to handle that?
|
|
|
|
|
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Matt U. wrote: contractor
I see your problem...
Most contractors are idiots. Not all of them, but most.
Same goes for the management that hires these goons. Most of them are idiots as well.
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???
|
|
|
|
|
Hmm. Not sure how to take that one. I was a contractor for 10 years and I think that I'm pretty good at programming. I do agree, however, that many "young" contractors, some that I have worked with, are over hyped and touting more than they are capable of delivering. Contracting for a living doesn't necessarily equate to being a poor programmer.
When you are dead, you won't even know that you are dead. It's a pain only felt by others.
Same thing when you are stupid.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
As I said, there are a few good ones out there.
I agree that the younger generation generally doesn't really know what they are capable of (I have met some that do, but they are the exception, not the norm).
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. I worked as a contractor for my first few gigs ('13-'14), but I've been on company payroll here since April '15. I don't see being a contractor any differently; I still take the job very seriously and I put in the same effort. I've also seen other contractors' work where they didn't seem to care a bit, however.
"Younger generation" being how young? I'm 29.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
I think that is the key, attitude. I don't think it really matters if a programmer is a contractor or not. I've worked with programmers, both contractors and permanent hires, who really didn't care if their work met standards as long as it worked.
When you are dead, you won't even know that you are dead. It's a pain only felt by others.
Same thing when you are stupid.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
That's young?
By 15 I was aligning heads on disk drives and terminating RS232 cables.
My first desk was literally a cable spool on it's side.
Great times.
|
|
|
|
|
With 12 I built my first computer.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I started tinkering with computers a while ago - maybe around '95 or '96. I've only been in professional developer roles for about 5 years though.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
I've found the chances of getting a good contractor for you, is about 50%.
As far as I can tell, being a contractor can make you a very good developer but perhaps the experience earned is shallow.
|
|
|
|
|
I can understand your position, but in my case, I have found that contracting made me more versatile, both in technology and business. Every contract that I had the pleasure of working was different from the others. I've worked in banking, insurance, publishing, medical, and scientific. I've worked for NASA, DoD, Juniper Financial, Cigna Insurance, Boeing and alike. The technologies I have learned over the years span from assembler to C#.NET, from standard HTML (from the 90's) to ASP.NET. I have also had permanent jobs that lasted up to 7 years, so I've had the best of both worlds. I've also had the pleasure of traveling to many cities in the U.S. and Europe.
It really boils down to what you make out of it. Contractors can be shallow if they are lazy and don't put any effort into their career. Those are the ones that can be and usually are shallow.
When you are dead, you won't even know that you are dead. It's a pain only felt by others.
Same thing when you are stupid.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
Another question is why would you want a query to be executed like that.
Assuming that "field1" and "field2" are fields coming from the UI (user), they could easily be manipulated to allow SQL Injection.
|
|
|
|
|
Not with Entity Framework. The placeholders in the query are replaced with parameter names, not the values passed in to the method.
Tracing through the code, you eventually come to the System.Data.Entity.Core.Objects.ObjectContext.CreateStoreCommand method. The relevant part of the code looks something like this:
if (parameters != null && parameters.Length > 0)
{
DbParameter[] values = new DbParameter[parameters.Length];
if (parameters.All(p => p is DbParameter))
{
for (int i = 0; i < parameters.Length; i++)
{
values[i] = (DbParameter) parameters[i];
}
}
else
{
if (parameters.Any(p => p is DbParameter))
{
throw new InvalidOperationException(...);
}
string[] parameterNames = new string[parameters.Length];
string[] parameterNamesWithPrefix = new string[parameters.Length];
for (int i = 0; i < parameters.Length; i++)
{
parameterNames[i] = string.Format(CultureInfo.InvariantCulture, "p{0}", i);
parameterNamesWithPrefix[i] = "@" + parameterNames[i];
values[i] = command.CreateParameter();
values[i].ParameterName = parameterNames[i];
values[i].Value = parameters[i] ?? DBNull.Value;
}
command.CommandText = string.Format(CultureInfo.InvariantCulture, command.CommandText, parameterNamesWithPrefix);
}
command.Parameters.AddRange(values);
}
So if you pass in the parameter values, rather than DbParameter s, the code will automatically create parameters called p0 , p1 , etc., and insert the parameter names into the query.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Actually looks like a pretty standard approach for SQL databases.
The SQLSTATE stuff is supported by Postgress, MySQL, MariaDB, SQL Server, surfaced by ODBC, DB2, etc.
It allows a query or procedure to return errors and/or informational messages. An error indicates processing could not complete, and informational message may, for example, warn of data truncation but allow the task to finish.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
It seems all the code I've been given to look at recently has not a care at all about scoping - every field, property, function and constructor is public and it is up to the user of that code to decide if they can, in fact, use it or not....
|
|
|
|
|
Back to COBOL?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Yes - except now with race conditions...
|
|
|
|
|
I used to work for someone who liked all the variables to be public so that he would have easy access to anything he wanted. There is a reason I don't work there anymore.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Yes, that's a great programming paradigm. Whenever you might need access to some property or function, you can do it. Well, better yet when everything is static or only one big class. YAGNI , SRP and Co. are for script kiddies only!
|
|
|
|