Am I the only one who thinks that the repeated attacks on drugs and drug usage are really unnecessary (and not well informed on the topic)?
How not to check the validity of an email address
161–170 of 243 posts
Re: How not to check the validity of an email address
#162Am I the only one who thinks that the repeated attacks on drugs and drug usage are really unnecessary (and not well informed on the topic)?
Nope, blog post was loaded with snark - her attitude offended me more than the poor code D:
Re: How not to check the validity of an email address
#163Somewhat unrelated, but out of curiosity, does anyone know of a site that lists — for all popular languages — various libraries/code snippets/routines which one can use to correctly (according to the RFCs) check the validity of e-mail addresses? If not I may be compelled to create one.
Check out this incredibly complex rfc822 regex in action: http://regex101.com/r/fZ6cD5
Re: How not to check the validity of an email address
#164Earlier quoted context omitted.
> Every single legacy application I've ever worked on has had analogous code buried in it somewhere. I'm not old enough to be responsible for stuff like that but I am incompetent enough.
I love your comment. Funny and humble.
Rest assured that while the person responsible for the legacy design flaw is perhaps long gone, I'll be right there...waiting, oblivious.
Re: How not to check the validity of an email address
#165I've once come across: if (!Boolean.FALSE.equals(aBoolean)) { // ... } I was pretty baffled.
I've seen a surprising amount of code that does: if (aBoolean == true) { .... }
eh, that's not so bad really.
If I were writing something, and I really wanted to make it clear that I was testing a boolean to be true, I might write that. Then I can be absolutely certain the person reading it in 5 years won't misread it.
Actually, the more I think about it, the more I'd be inclined to do that in the false case ( ie if(aBoolean == false)... rather than if(!aBoolean).. ) because I worry that it's too easy to skip over the '!' - and I personally read that as "not aBoolean" rather than "aBoolean is false"...
I'll bet it complies to the same thing anyway, so it's just about readability at this point.
Re: How not to check the validity of an email address
#166Every single legacy application I've ever worked on has had analogous code buried in it somewhere. An application I've just been "repairing" recently has a spot where it uses two separate queries to pull two full table sized lists of values, then manually joins them with a loop, and then manually re-orders the joined values into groups selectively ignoring some rows, and then embeds the the whole reordered list in a…
> hiring random "programmers" who have history or psychology degrees and think they can program because they made a form in PHP. That's pretty unfair to people coming from history or psychology who actually can write good code. Just because you don't have a degree in CS doesn't mean your code is shit. This is purely anecdotal, but my predecessor at my current job was a CS graduate and wrote code like in the OP.
I knew a music major who was a better coder than most of the CompSci grads.
At one job, I judged coding ability by the number of times your SQL woke me up due to huge I/O usage[1]. Many a CS graduate cannot read a query plan.
1) if it looked like a reasonable query and it was just Sybase's crap optimizer, I gave them a pass. Although, after a while, you learned to force the indexes.
Re: How not to check the validity of an email address
#167Earlier quoted context omitted.
I've seen a surprising amount of code that does: if (aBoolean == true) { .... }
At university I worked with small unmanned aircraft. We had a crash due to a piece of code with this form: int landing_flag; ... if( landing_flag ) { do_landing(); } It was C code that pre-dated a boolean type. A single corrupt data packet in a wireless link made landing_flag == 2345923 (some arbitrary large value) and thus the landing routine was triggered mid-flight. We changed every instance of if( flag ) to if( f…
So, you changed a somewhat reproducible bug into one that has about a four billion times lower chance of occurring?
Good luck to the poor chap who will have to figure out what happened when that bug hits.
Also, you introduced a new error condition: a corrupt packet that should set a value of 1, but arrives as a value of 2 will not initiate the landing routine.
The right thing to do, IMO, is to prevent corrupt data packets from doing such stuff. Checksum the packets or, better yet, checksum and encrypt them. That prevents the enemy from taking over your plane.
Finally, I do not see how 'no proper bool' is relevant here. If the packet contained a single bit indicating the value of the flag, it still could get corrupted.
Re: How not to check the validity of an email address
#168Every single legacy application I've ever worked on has had analogous code buried in it somewhere. An application I've just been "repairing" recently has a spot where it uses two separate queries to pull two full table sized lists of values, then manually joins them with a loop, and then manually re-orders the joined values into groups selectively ignoring some rows, and then embeds the the whole reordered list in a…
> hiring random "programmers" who have history or psychology degrees and think they can program because they made a form in PHP. That's pretty unfair to people coming from history or psychology who actually can write good code. Just because you don't have a degree in CS doesn't mean your code is shit. This is purely anecdotal, but my predecessor at my current job was a CS graduate and wrote code like in the OP.
I became an English major because I'd been coding since I was six years old and preferred to learn how to become a better writer.
At the time, the majority of incoming CS freshman did not even harbor the most basic ideas or curiosity about how a computer functioned. They had all heard they could make mounds of money. When I took elective CS classes in college, I had graduate CS students attempting to copy off of me.
It's possible CS students and programs have changed since the 90s, but based upon the CS graduates I encounter, I expect they haven't improved that much.
Re: How not to check the validity of an email address
#169Earlier quoted context omitted.
This story almost had me in tears (a mix of schadenfreude and shame for my profession). I hope they learned something not to give business critical work to college students. Makes me think that IT Risk management should be right at the top of what MBAs have to learn.
Wow. Just because someone is a college student doesn't mean they are incompetent! Plenty of people do business critical work as college students, haven't you ever heard of co-op before? A degree doesn't make you competent either, I've worked with enough people who have degrees who are completely incompetent. College students might need some extra supervision to make sure they are doing the right thing, but so do jr e…
I think you got me wrong, sorry for not having myself made clearer. I worked through college as an IT consultant as well, however as you noted under supervision of a consulting company with seniors. Hiring a college student directly, without a company attached that can be made liable, is just a bad idea, both for the customer and the student. Just imagine the customer had sued parent. I wasn't talking about technical competence - it's all about liability as well as having proper processes for design, implementation, review, testing and rollout in place - a thing that can easily he seen even before signing a contract.
Re: How not to check the validity of an email address
#170Earlier quoted context omitted.
I've seen a surprising amount of code that does: if (aBoolean == true) { .... }
eh, that's not so bad really. If I were writing something, and I really wanted to make it clear that I was testing a boolean to be true, I might write that. Then I can be absolutely certain the person reading it in 5 years won't misread it. Actually, the more I think about it, the more I'd be inclined to do that in the false case ( ie if(aBoolean == false)... rather than if(!aBoolean).. ) because I worry that it's to…
Why stop there? To really get the point across, you may want to do:
if (((((a == true) == true) == true) == true) == true)
That way, you can be even more certain!