Error checks? Eh? What could go wrong, really? (DoSing a US govt site) It's time for your dose of Line Break, our Wednesday column of coding nightmares that have haunted Register readers at one time or another. This also means we're already halfway to Friday. Judging by some of these following tales, we can only assume one too many developers out there are already half cut by this point in the …
The moral is never do it, period.
Don't say "unless you really know what you're doing". Cowboy developers are always certain that they really know what they're doing until it blows up in their face.
Or yours, if they're not there anymore and you're left holding the candle.
Moral on the -1 passed as array index? The moral is never do it, period.
The moral is, define an appropriate type that is ok with taking -1 as an index while normal arrays would throw.
That's what types are for.
They are statically (sometimes dynamically) verifiable constraints on the crap we produce.
And then you still lhave asserts and contracts of course.
You will find a lot of library functions, i.e. searching into an array, that will return -1 if not match has been found. Unless you have nullable types, or exceptions (but the latter may be a bit too "heavy" for a "not found") - few languages allows arrays with arbitrary ranges (Pascal, for example, does), thus -1 is one of the few available choices (another may be to return true/false and the index as a parameter, but less practical to use, say, in a for loop...)
Look for example at std::string::find and std::string::npos - both of which doesn't look to be written by "cowboy developers".
An array index of -1 can certainly be used, in languages like Pascal, or even Fortan, or, with care and documentation in languages like C(++). For some arrays it is natural to have an index range of e.g. -N to N. In Pascal-like language you just declare the array that way. It is not that difficult to get it right in C(++).
It seems to me that the key problem is the silent coercion of a signed int to an unsigned int. Strong typing would have trapped this error, I feel. If I already have element numbers 0, 1, and 2, and add element number -1 to a dynamically allocated array, I can do that by allocating a 4 element array, incrementing the pointer, and copying the data to the right elements. Of course, when freeing the array, you must first decrement the pointer accordingly. Writing a class to do this safely is not that hard, although there is every chance people get it wrong.
Incidentally, I am reminded of a coding problem a student of mine encountered, when trying to implement a method found in a scientific article. The first part dealt with image representation using particular polynomials, the second with image or object recognition with the same type of polynomials.
This was a good student who first coded the first part, and when that worked well, coded the second bit using the same code for the polynomials as before. Result: Crashing code. He worked on this for several days, trying to find the bug. When I came to look, I suddenly noted an odd thing: In the pseudo-code in the paper, the first part indexed the arrays containing the polynomials from 0 to N-1, and the second part used a different convention: 1..N. Accessing element N caused the crashes. Ouch! Easy to sort, but really frustrating!
Actually, the code had two problems:
1) a signed value was silently converted into an unsigned one
2) The array was dynamically sized without any check for available memory, or a max allowed size.
The latter actually hindered to access memory beyond the array, but of course killed the machine...
if ($("#img").attr("src") == null) {
$("#img").attr("src", $("#img").attr("src"));
}
This stinks of jQuery. jQuery is an abomination. I've lost track of the number of times I've heard "I can reduce your n lines of javascript into q lines of jQuery" from someone who doesn't understand that jQuery involves pulling in about 2 hexatrillion 'lines' of javascript.
It makes me sad.
Now, get orf my lawn
I can't comment on the code except that it looks a bit odd. It could be, and probably is, just shitty code but the same logic could be written in any language.
I heartily disagree. The world before jQuery was very unpredictable with lots and lots of slightly differently own-rolled code.
jQuery is helping standardise common use cases that, in turn, help standardise the language development and browser implementations. Indeed in many situations it is becoming a victim of its own success: more and more stuff can be moved into CSS. I'm looking forward to seeing more of this.
The reason jQuery is fast is because it _doesn't_ run all those lines of code in most browsers. The browsers have it baked in. Most of that code is "Sizzle" (sizzlejs.com)
"Sizzle" is the reason that rubbish old browsers run jQuery just the same but much, much slower. Those old browsers have to execute all that code in order to emulate the functionality that is built into newer software.
My guess for the funny javascript code - It was supposed to do some sort of image lazy load.
> 1990s: a user prompt from global logistics system developed internally and rolled out to 30-plus countries.
Are you sure you want to cancel the shipment?
Yes / No / Cancel
So kinda like the HP Print Service plugin for android that in 2016 asks whether you are sure you want to cancel your print job.
OK / Cancel
At least the keyboard not found press any key message has a bit of logic behind it; after resolving the problem you can actually follow the instruction.
That was the theory. Unfortunately most keyboards prior to USB such as PS/2 but also the old DIN connectors which were electrically the same were not hot pluggable and doing so could, but pretty unlikely to in practice, damage the control circuitry.
Personally I start thinking about error state handeling whenever I code anything, but then again I am not a "coder" but a mechanical engineer (I program some basic PLC and Arduino stuff every now and then. When there is hardware in the mix error handling becomes that much more important)
My favorite was standing behind one of my programmers one day and watching him run the program that he was working on though the 8048 assembler (yes, this was a long time ago) - the assembler completed, without generating any error messages and he said "Finally, it's working!"
At that point I realized what the problem was - he thought that if the assembler didn't generate any error messages ... then the program must be error free.
I gave him his exit interview later that day.
@Version 1.0 My favorite was standing behind one of my programmers ... I gave him his exit interview later that day.
So, the boss hangs over the guy's shoulder while he's working - no pressure there. He lets out a slightly ill-judged expression of pleasure when he gets a clean assembly. So you sacked him.
I think he had a lucky escape.
I had been babying this particular guy for about three months listening to his presentations on why writing code for the tape deck controller was going so slowly - the exit was friendly and I told him that I would give him a good reference for any job that did not involve programming. His problem was that he did not comprehend - even after we discussed it - that an assembly pass that did not generate any errors did not mean that the code would actually function.
After he left I sat down and wrote the controller code myself in about a week - it turned out that wasn't that hard although since it was controlling a tape deck it did need some careful planning.
The last time I saw him he had a very nice job with another company in marketing and was making more than I did.
"His problem was that he did not comprehend - even after we discussed it - that an assembly pass that did not generate any errors did not mean that the code would actually function."
In neither version of your story do you address one essential point. Did his code work?
"In neither version of your story do you address one essential point."
In neither version of their story did they mention whether the tape deck controller would then sound out Beethoven's 9th. Have none of you worked with people like the mentioned 'programmer'?
One guy was given some thousands of lines of network code I'd written to maintain. His method for learning that code was to line by line _manually_ reformat the source to his preferences. That way he would have 'read' every single line and would 'understand' the code. Of course this mere transformation could not possibly introduce problems... That could not possibly be revealed with available diff programs. And no, there were (then) no automated source reformatters available either.
I'm not ashamed to admit that upon being asked by him to explain some bit of 'difficult' logic, upon seeing what he had been doing for the past weeks of 'reading' I squealed. As in pig and knife and stuck.
Weeks he'd spent destroying the ability of anyone to help him. Truly, truly, some people are not fit to deal with code. Version 1.0 did the right thing for everybody's sake and was downvoted. Foo.
"My favorite was standing behind one of my programmers one day and watching him...."
I can only imagine just how calm, comfortable, unpressured and in no way likely to make any stupid mistakes that guy was with you leering over his shoulder, ready to sack him at the slightest sign of not being the bestest best programmer ever.
The beer is for that guy.
"Error free!" - Your title is best understood as being cognitively similar to the air force squadron leader instructing his fellow fighter pilots, "Weapons free!" - meaning, "Destroy anything that looks crosswise at you!" Similar, the program is ready to destroy anything in its path, most likely at an unpredictable moment with the highest potential of catastrophe! :D
Chatting to a supposed programmer some years back, he claimed he had a simple way to get out of heavily nested code. At the desired exit condition he simply wrote a line that would throw an error, and used the system's exception handling. Apparently he selected ones that his programs couldn't possibly throw in reality.
I'm pleased to say I never even saw any of his code.
It's one of the recommended ways of getting out of a deeply nested structure in any well-structured programming language. Was the problem with a lousy language that did not allow an all-but-infinite number of distinct user-defined exceptions which can be handled while allowing other exceptions to propagate unchanged? If not, raising exceptions is a perfectly sane thing to do. Often the best.
There are those who say, (and I tend to agree) that this is exactly why exception handlers are the devil's spawn, combining the worst elements of gotos and segfaults! Yes, they _can_ be used, carefully, in such a case - but you are leaving all context behind, eliminating any possibility of maintaining state except by manual labor. There was an essay ... in fact there have been several:
http://www.lighterra.com/papers/exceptionsharmful/
> "Exception handling introduces a hidden, "out-of-band" control-flow possibility at essentially every line of code. Such a hidden control transfer possibility is all too easy for programmers to overlook – even experts. When such an oversight occurs, and an exception is then thrown, program state can quickly become corrupt, inconsistent and/or difficult to predict (think about an exception unexpectedly being thrown part way through modifying a large data structure, for example)."
> "Exception handling does not fit well with most of the highly parallel programming models currently in use or being explored (fork/join, thread pools and task queues, the CSP/actor model etc), because exception handling essentially advocates a kind of single-threaded "rollback" approach to error handling, where the path of execution – implicitly a single path – is traversed in reverse by unwinding the call stack to find the appropriate error handling code."
http://www.joelonsoftware.com/items/2003/10/13.html
> "The reasoning is that I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:"
http://blogs.msdn.com/b/dennisg/archive/2012/04/28/exceptions-considered-harmful.aspx
> "The doctrine of object-oriented programming dictates that exceptions are the mechanism of choice to raise (and, possibly, handle) severe error conditions that cannot be safely ignored by the client code. Let me just take a step back to explain why I think exceptions are all but inappropriate in most situations by definition."
I had a reporting database once that mimicked the progress bar. It started off sensibly enough "Copying data to reporting table", "Analysing data", etc. About halfway through the messages would change and you'd get "error found in user", "electrifying keyboard", "deleting database".
I then handed it to one of the technicians to run as a test...
I then handed it to one of the technicians to run as a test...
Someone once asked me why he could not type a file (on VMS: think "cat" on Linux). QVX was not a well-known file type. The error was a well-known VMS error message which I am reproducing from memory, perhaps not quite correctly
$ TYPE myfile.QVX
%SYSTEM-E-FNF, File "myfile.QVX" not found.
$
I was starting to worry about a possibly corrupt filesystem (we'd recently had disk drive troubles) when the penny dropped as to what was really going on.
Haven't used VMS in years. My first "IT" job was report writing from an AS400. I was actually an engineer so would go to the IT team to get queries written, until after a while I realised that I actually understood the system better than the IT guy who I was getting to write the queries.
After that had to support a VAX system (PROMIS, used for wafer fabs). That was the job where we bought a java based GUI for the system that was so incomprehensible (different buttons with random images that had no descriptive text) that I redesigned the entire GUI from scratch. The other flaw was it's "traffic light" warning system. Fine in a standard manufacturing room, but this was specifically for wafer fabs. Wafer fabs have at least 1 room (photo-lith) with orange lighting. You can't see the different colours.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
