When customers try to be programmers: 'I want this CHANGED TO A ZERO ASAP' Welcome to the first proper installment of Line Break, the weekly column in which Reg readers share truly horrifying code they've seen in the wild. We started you off last week with a pilot episode involving some close encounters of the absurd kind – and we've had fantastic responses from Vulture fans, which we'll roll out …
But now I'm worried that at some point in the future something awful I once did will be pilloried here. And even though nobody knows it was me, I will be mortified.
So let's be clear; most software foul ups are organisational foulups. Failure to test, failure to specify, failure to put proper procedures in place, expecting people to work excessive hours, responding to customers without stopping to think.
That, array handling and loop exit conditions.
"[...] expecting people to work excessive hours, [...]"
Many of the problems I had to clear up in other people's code - were where they had stopped working at an inflexible point in their working day. What could be called 9 to 5 patterns. When they returned after the break - they didn't continue the code properly as they eased themselves back into what they had been doing.
I tried to leave - early or late - when there was a clean break that didn't leave hanging threads in the middle of a piece of coding.
Been there, done that and probably have the shirt somewhere, although it was usually only a frustrating 45 mins at most. Ah the follies of a youthful coder who thought he knew-it-all, only to be slammed back to earth by the genius of an inadvertent infinite loop!
With all the 'clever stuff' snipped out for the example, it may have been slightly less obvious; there may have been references to SUCCESS in that, but which didn't set it at all, so it becomes a wood for trees situation.
It does bring to mind my younger days. On a YTS at college, when the class was doing some programming. The instructor was trying to help a girl with her program, but couldn't understand why, when run, it appeared to do nothing.
I took a glance, pointed to a part and said it's an infinite loop - with a quite similar cause to the example here. The instructor told me I was wrong (IIRC, I was told I couldn't possibly spot such a problem so quickly) so I stepped in, added something at a key point to display the contents of the test variable on screen, and ran the program again. Unsurprisingly, the screen just scrolled the same number on each new line.
I then got told off for "breaking" the girl's program.
This post has been deleted by its author
"Ah, the joys of a teacher who doesn't want to be shown up. Far too many of them in the world..."
Yeah, but things did change. I can't remember how far into the year that was - but as it progressed, the guy did come to realise what I was capable of. Somewhere down the line I stopped being a student and started assisting, and at one point while the class was learning some rubbish or other he tasked me with writing a nice little database for his model cars.
Well it is obvious NOW. In my defense there was a lot of other things going on in the code. But definitely a slap in the head moment after. And no, no issues with hours or anything to justify it.
Thankfully I don't recall if I wrote it or just spent the time trying to fix it.
Well, even if that one can't be spotted, any decent analysis tool would report what's up within nanoseconds.
However, it is a common problem, especially in organizations that do hardware (including mechanical) and software that they will spend £LOTS on physical tooling, but £ZERO on software tools.
Don't get me wrong, I'm with you. A properly typed language (like Pascal) wouldn't allow SUCCESS to be assignable (because it would be a const) and wouldn't allow an int as a Boolean (without explicit typecasting).
However, if you think this sort of minor sloppiness (characteristic of curly bracket languages) is bad then never (NEVER) even think about looking at the crazed lunacy the PHP type hallucinator can come up with.
What would change is the code would visually scan as:
while True do
begin....
...which is obviously suspiciously infinite. When you check the block and find no break, goto or exception you have the bug. No possibility of SUCCESS changing value in a pass by reference function.
"I'm ashamed to say this took a good week and two engineers to work out,"
Eh...? Actual programmers were they? Or civil engineers or what have you?
Anyway, thanks for making me feel good about spotting the issue as soon as I read the relevant code even almost... 15 years, I think it's been...? God $deity! But time flies!!... since I last actually wrote any code.
That example was (presumably) an easy one, no change to tested variable/condition.
What does catch folk out is when "SUCCESS" is supposed to be changed in some asynchronously called function (interrupt, or signal), maybe in another file, in which case the bug is usually not declaring it as 'volatile' and the compiler optimises the test to an endless loop, instead of checking the memory location "just in case"
This post has been deleted by its author
What does catch folk out is when "SUCCESS" is supposed to be changed in some asynchronously called function (interrupt, or signal), maybe in another file, in which case the bug is usually not declaring it as 'volatile' and the compiler optimises the test to an endless loop, instead of checking the memory location "just in case"
Been there, done that, a few times. I've also done the simple version as above - usually as a quick hack to fix/check something else and then kicked myself a few minutes later when I actually read the code. Sometimes one has to really screw up to hammer home the point, at which stage the embarrassment (even if only internal) stops it happening again.
I can recall ancient fortran compilers that would "optimize" pseocode like this to a loop that was either executed once or forever:
while (rand(j) < 0.5) {
Do stuff
}
Because j never changed in the loop, it assumed that rand(j) never changed and optimized rand(j) outside the loop! And of course, half the time the loop would execute once, and the rest of the time it would never exit.
And then you have a new bug, because volatile does not erect a memory fence so your data access is unsynchronised. What you should really be doing is surrounding both the get and the set with MUTEXES ... and then volatile has no further effect anyway because the mutex prohibits the optimisation you were trying to avoid. Conclusion: volatile is irrelevant for multi-threading. (It still has value when you're reading from a memory location populated by some low-level piece of hardware ... say it's mapped from a PIO or something ...)
I have an invisible serving spoon. Every single frigging time, crock of hot roast potatoes slowly heating up my hand through the oven glove and I'm stood looking at a milk jug stuffed with utensils, entirely unable to see the very shiny metal serving spoon that's right in front of me. And it's not just me... my flatmate's the same. We can both spend ages searching through this forest of utensils looking for the spoon that is right there in front of us.
We can both spend ages searching through this forest of utensils looking for the spoon that is right there in front of us.
What I 'love' are those instances where you drop something important, can't see it for looking, give up and put your eye's/hand on the dropped item straight-away, as if you knew where it was all along...
"Akin to real life, when looking for car keys. If they are on the desk right in front of me, I don't spot them."
Hold some imaginary car keys, insert into an imaginary lock and twist. The real car keys will magically appear. This trick will work for any distinctive tool that you have recently seen without noticing.
Using UPPER_CASE for a variable name makes it read like a #define which you would expect to be a constant anyway (yes, I know that upper case for a #define is a convention, but one pretty much adhered too) which immediately draws one's attention that the while() conditional probably isn't changing...
I.e. doing something weird alerts the hapless engineer to the issue for the wrong reason...
That's assuming the code is C though...
Two weeks though? I spotted it in under a micro fortnight!
One thing that bugs be about that comment is that it doesn't explain (even vaguely) why making the change would be so disastrous ... there is not even a "I don't know why but in all my testing shows that ..." remark. And it's not like the comment was some really terse one-liner, which might well lack such detail (eg simply "DO NOT CHANGE THIS EVER!!!")
Perhaps it really /was/ deliberate booby trap ... but then why the warning?
It all seems rather odd to me.
Right. Also there's a "glitch" that leads to think that value should be changed. Why the "glitch" wasn't removed the proper way in the first place? If it couldn't be removed but with major changes, it should have been documented there or somewhere else (with a reference in the code), i.e. in defect tracking system - and still customers may not like software exhibiting "glitches", thereby it has to be fixed eventually.
It looks a case of "it works this way, never touch it, because we don't know exactly why it does, but if you change it, it's worse". Not the way I like to develop software.
Back in the day, I'd stumble across glitches in the OS, compilers, libraries and such. I'd lay a detailed explanation in what's wrong, what my fix does, and when the vendors were notified so when a new version came along, the maintainer could just search and the bug fixes in the codebase would pop-up. I knew that I definitely wouldn't be around forever so it was just the courteous thing to do.
All new bugs were theirs.
CSB:
I have a Bosch refrigerator. It's very nice. However, it does have one feature which I have never before seen on a refrigerator: an on/off button. We installed the refrig, and were surprised to see that the light didn't come on when we opened it. Read the manual, found the button (at the top, near the hinge, marked with the circle-with-a-short-line power symbol), pushed it, and all was well.
Fast forward now, to the day we came back after a long weekend. Cleaners had been in and one of them had thought it a good idea to press the power button, thereby turning off the refrigerator. They do a good job cleaning, but frequently do something random like this. Luckily, it had only been off for 24 hours and things had not thawed.
There is now a prominent label next to the power switch: "DO NOT PRESS THIS BUTTON".
Good idea.
The Germans (or Chinese) had thought of that. The button, which is located on, and sits proud of, the mating surface, fits into a carefully crafted recess in the door itself, meaning that the cover would need to fit into the space between the button and the recess, in order for the door to close.
I haven't crafted the custom cover yet :-)
I'm puzzled that someone even thought an on-off switch was necessary on a refrigerator. At least, they put it high enough so that inquisitive little fingers couldn't reach it.
if you had to press a button to turn the fridge on, what happens after a power cut?
My freezers have a power on button, if power is off for more than a few hours and/or the internal temperature rises to a critical threshold (ie. the door has been left open), it will either power off totally or won't power back on. It's a feature to do with food safety and preventing the refreezing of unfrozen food.
because it never passes the value of "status" to "SUCCESS"? or never tests if status == SUCCESS?
We had a brilliant one at my old company in the UK, an officious manager who said in a meeting "I should know, I used to be a DBA" and the head DBA (very technically capable) said "Yes but you weren't a very good one".
While variable names and styling give an indication of what the variable is and does, you can't (and shouldn't) rely upon this. If you want the variable to be a constant, define it as such.
const int SUCCESS = 1;
You say it is a widely followed convention, but it isn't one I have seen in the organisations I have programmed with.
<<We had a brilliant one at my old company in the UK, an officious manager who said in a meeting "I should know, I used to be a DBA" and the head DBA (very technically capable) said "Yes but you weren't a very good one".>>
Bit like this ---> https://www.youtube.com/watch?v=x-a5B6xM5s4 (takes a while but you'll see what I mean)
Not all of us here are programmers and I could stare at that code for an eternity and not know what I'm looking for.
I do a little HTML, CSS and PHP and some aeons ago a small amount of classic ASP, all of it laughably simple. I've always thought of coding as a little like Shakespeare; I can read Shakespeare, I can understand (some) Shakespeare but I certainly can't write it.
"it should say: while(status == SUCCESS) {"
I was half expecting it to be a case of "while(status = SUCCESS)", the classic schoolboy C-style error of assigning a variable, not testing. Why I was always taught to have "constant == variable" as the test, so that any missing = would throw an error.
Just to be pedantic :) you should probably get into the habit of reversing the test ie.
while (SUCCESS == status)
Assuming you actually remembered to make SUCCESS a const, or a #define, this stops you causing another disaster by accidentally omitting one of the = signs - you'd be stuck in the loop again.
Actually, I've seen similar cases where the loop would exit, though unpredictably, owing to the equivalent of getstatus corrupting the stack (or failing to preserve registers). Those ones really do warp your mind.
Though any decent compiler in the example quoted should have optimised out the test and issued a warning...
"Actually, I've seen similar cases where the loop would exit, though unpredictably, [...]"
The fictional scenario of passengers waiting for the lemon-soaked tissues unusually overlooked the unreliability of any cyclic state continuing forever. There is always an "unknown unknown" - or even just a "very unlikely known" - that will cause it to end prematurely.
Given that it uses an ancient COBOL idiom, it really is kinda like Shakespeare (COBOL originally only had do something until ... loops, where the test is made at the bottom before looping back). Applying that idiom in 'C' or similar is a fine cause of malarkey when you use it with do something while ... loops, where the test is at the top of the loop. Full marks for 1TB though.
Keep at it though - simple things usually only appear that way because you've kept your wits about you.
"[...] where the test is at the top of the loop. "
IIRC Pascal always executed a FOR loop once - even if the condition suggested the limit had already been reached. One of the Pascal "Common 10 mistakes" when moving to it from another language.
Always felt that "C" could have done with := rather than = for assignment. That would have prevented the = and == mistakes in C.
I think if you aren't a programmer then this may not be the series for you. Although the web server that executes any UNIX command in the URL (in it is in fact doing that) doesn't require a programming qualification to appreciate. So efficient! :-)
I can imagine encoding an "rm" cleanup command in the parameter which would invoke the equivalent actual "rm" command on the server, without recognising any other UNIX command input.
But even then it might be unwise.
"Although the web server that executes any UNIX command in the URL [...] doesn't require a programming qualification to appreciate."
In fact, anyone who reads El Reg thoroughly will (at least this week) appreciate that a remote attacker could even wipe the UEFI firmware on your server this way.
The stories are all good. Perhaps they are too good. I know truth is stranger than fiction, but that also means that sometimes it is harder to believe.
Do you have expiremental evidence that a duck is more effective than a more traditional SITSE partner?
The last one looks obvious - but it is a case of the brain seeing what it expects to happen - rather than what the instructions actually will do. Lay people have difficulty in understanding that you can't lie to a computer - being too precise can also be wrong if there is an unknown factor.
In the old days it was the sort of problem that you knew you just couldn't see for looking - it had to be obvious.
As a very occasional drinker I would look at such a problem while working through three glasses of whisky. The increasing intoxication meant my thinking became slower and slower - and eventually I had to reason very hard about each step in the code.
Usually I spotted it by the third glass - otherwise I went to sleep. If I was lucky the answer rose unbidden as I awoke the next day.
That only works if a small amount of alcohol has that effect on you - regular drinkers would have a higher threshold.
I find tea has a far quicker effect. If by the third mug you haven't solved it, you simply set a condition "I cannot leave my desk until this is solved." The problem then quickly shifts to one's secondary (some might say primary) processing centre located around the pelvic region.
If you piss yourself, you can declare the problem insoluble.
"I cannot leave my desk until this is solved."
Sometimes it is the act of leaving your desk that gets the mind off its tramlines and the answer becomes clear. Many times in my career I have given up on a problem and left the office. Then 100 metres down the road had to turn back as the answer had just occurred to me.
Managers often put the coffee machines in working areas so the staff don't spend too much time away from their desks. In fact it is the break of a moderate walk that is often most productive.
"Many times in my career I have given up on a problem and left the office. Then 100 metres down the road had to turn back as the answer had just occurred to me."
This happens to me ALL THE TIME - although normally when I'm about 200 metres from home rather than 100 metres from the office.
It is intensely annoying, as I then have to try to *remember* the solution for the next day!
"Then 100 metres down the road had to turn back as the answer had just occurred to me."
I used to wake up in the middle of the night with the answer to a lot of problems. On more than one occasion I realised that I had been barking completely up the wrong tree and a different approach was needed. That's why I don't believe in "stay till its fixed". It just puts pressure on to come up with a fix without unravelling too much code that should not have been written like that.
I guess it depends on your mindset. One partner at my father's firm used to deal with case papers, instantly forget each one when he was up to date, and then start the next case. He would get through his caseload, go home and play bridge. My father, on the other hand, might have several things going at once but left the office promptly at 5:30. During the evening he might have a eureka moment, scribble a note to himself and deal with it next day. They both seemed to do about as well as one another.
"Many times in my career I have given up on a problem and left the office. Then 100 metres down the road had to turn back as the answer had just occurred to me."
I think the explanation is that we have a fairly full mental model of whatever it is we're working on but what's on the screen focuses us on a tiny part of it. Leaving the screen removes that focus but the model only decays slowly so that the brain is able to keep working on it unconsciously for some time.
I found the solution might pop up as I walked across the car park. Or just having joined the motorway - concentrating on driving must have been particularly effective at removing the last elements of the screen focus.
The bug is fairly obvious. I suspect though that the circumstances of the actual execution, and the knock on effects (software gets stuck in a loop) may have been non-obvious. The OP doesn't say whether this whole thing was conditional... i.e. maybe the whole code isn't triggered very often. Or maybe it's triggered by a non-obvious scenario. Imagine this was in the controls of a custard factory machine, and it is part of the nozzle blockage handling routine... Maybe the nozzles don't get blocked very often. Maybe they do but the whole factory gets coated with custard and so diagnosis of what went wrong is 'sticky'. However what it does point to is a lack of automated testing of the software. Which should have found this particular issue quickly... solving it shouldn't take 2 engineers though.
Maybe the engineers were being charged out by the hour ;)
Maybe the first one couldn't work after injuring himself through laughing.
"Do we now have an explanation of the bag with 59 sachets of salt and one crisp?"
Happened to me when the salt was in little blue twists of paper. There were also reported cases of 1 baked bean in a can of tomato sauce.
Google found this in several newspapers recently
http://www.express.co.uk/news/uk/639922/Student-lifetime-Kit-Kats-legal-threat-wafer-less-chocolate-Nestl
This is pseudo code as I remember it from many years ago. The function was many pages long in practice, with lots going on. And part of a system where other components were passing the success to it. Multi Threaded and all.
and yes we felt very sill afterwards. We have all been there.
Sure I wasn't going to send an example of good code was I!
Surely in the first example there was a moral obligation to all other stakeholders in the company. An edited version of the comment (minus the "idiots" "fools" "morons" ad-hominem bits) should have been made available. "The full code contains this cautionary comment ... please confirm, in writing, that you nevertheless require the change which is so strongly cautioned against to be made".
Maybe the moron would have had second thoughts. And maybe you should even have tipped off his CFO, though you'd probably have needed to go up to board level of your own company to get that approved, and doing it without approval would take a lot of balls.
"So I show the code comment to my boss. He shrugs his shoulders and says:
"Well, go do it – it's what the customer wants..."
Nick tells us the company in question, true to the source code comment's warning, is no longer in business. Lesson: Customer is always right."
The customer was being a major asshat KnowItAll and wanted it changed and wouldn't accept no or reasoned argument for an answer. In the circumstances Nick did the right thing checking with his boss - I just hope this was one part of some major in triplicate arse covering before Nick made and delivered the change as demanded by the customer. The customer got exactly what they wanted.
It would be interesting to know how much this change contributed to said company's failure and whether it did so according to the prophesy of the comment.
I was wondering that also... <absurd mode on> so maybe he wrote the code, hated the place he was working... and shorted the stock in his possession. Company slides to the bottom of the pile, he makes a fortune on the stock, and gets revenge. <absurd mode off>
Absurd maybe... but there is the question about how did he know the line...? And the motivation for changing it?
Many years ago as a junior support programmer I was supposed to help experienced applications people with intractable problems in their programs. This meant someone would put a listing on my desk and say "the machine's faulty" - showing me the failing section of code.
I would often be looking at a programming notation I had never used or being trained in. So I would progress through the code saying in all honesty "and what does that do?" - and they would explain it to me. It was amazing how many times the person would soon say "Why of course - that's the answer - you are clever!".
Throughout my long career it was a good technique for helping people to solve their own problems.
I do this as a sysadmin - when trying to help our devs sort out issue and figure out if it's a systems or a devs prob - I'd sit down with them and they would show me stuff and then we would go through stuff more or less line by line.
It's one of the more fun aspects of my work to be honest. As frustrating as it can be at times it's fun.
Guess it helps that most of my learning of coding was through pseudo code(some actual coding as well but the good stuff was the pseudo code stuff) and actually tracing through that required pen and paper to solve at times.
Throughout my long career it was a good technique for helping people to solve their own problems.
And throughout my career, it is a good technique to teach junior programmers to write good code with comments ie. code wasn't just to be written. Plus they got exposure to many programming styles, some good some terrible and hopefully they adopted some of the better practises.
I would often be looking at a programming notation I had never used or being trained in. So I would progress through the code saying in all honesty "and what does that do?" - and they would explain it to me. It was amazing how many times the person would soon say "Why of course - that's the answer - you are clever!".
Throughout my long career it was a good technique for helping people to solve their own problems.
In other words, you were being a "rubber duck" ;)
I don't know when I discovered it but it was way back some 40+ years ago that problems just stuck with me and I absolutely had to solve them. Invariably I talked to other folk not even involved about them and discovered the answer during that talk. One thing I found helpful was to convert the problem to something the other person understood (eg: auto mechanics). When spark plugs are used in place of blahblah and they ask "what if you used different spark plugs" it is amazing how quickly the light gets turned on.
That thing about using all CAPS for constants or defines or whathaveyou? Never heard of it. I taught myself programing from books on machines that didn't have lowercase. Some of those machines I built myself. Even back then all CAPS was like being shouted at. As soon as lowercase was available, I jumped on it and tend to do everything in lowercase. Sometimes I may use CaMeLCaSe but it is rather rare. I always forget if the "l33t" way is with the consonants being upper or lower or if it is some random schmeck that someone is throwing out there.
we used to customize our product for individual customers, so we maintained a DAT tape of the source code specific to each customer.
Rarely a good idea. Over time as the codebases diverge even the simplest bug fix becomes harder and harder to to apply to each custom build, and takes longer each time. Eventually you end up doing nothing but housekeeping and no new development (I've seen it happen, just before the company in question ran out of money).
It's also risky, we once had a supplier that did this with #ifdef-type processing. When looking at a new code drop one day I saw code that was unrelated to our product. Not only that, it was clearly code for a competitor that I should not have seen. Relations with the supplier were very cordial, one phone call later produced a new code drop, and an embarrassed request to delete every copy of the old one and forget we ever saw it. Trust works both ways, so of course we did so, nothing more ever came of it.
I would have kept the code into a VCS with customer branches - as long as the customization are not large enough to make each of them a separate product. It could also be helpful to identify common parts which don't need customizations (or only little ones) and move them to a separate "core" project.
But I've seen too many project start as a custom project for customer X and its peculiar needs, then trying to sell it to Y and Z, of course trying to customize for their peculiar needs also. Soon you have a Frankenstein project - if you don't take the time to redesign it and isolate "peculiar" needs.
"But I've seen too many project start as a custom project for customer X and its peculiar needs, then trying to sell it to Y and Z, of course trying to customize for their peculiar needs also."
I nearly got sucked into one of those. It was also a case of "If that's where you want to go I wouldn't start from here", largely in consequence of the peculiar needs of X. It was monolithic so every user had access to every function in the system. It needed a re-write just to remove the spaghetti tying the multiple functions together.
Then the salesman persuaded Z that it would be a drop-in replacement for their existing system despite a misfit of data architectures...
I managed to escape PDQ.
"Then the salesman persuaded Z that it would be a drop-in replacement for their existing system..."
No way, can't believe it. An honest, knowledgeable salesman promising the earth to get a sale and then letting the tech team/customer sort it out afterwards. Scandalous, never happened in the history of the earth.
One strand in many programming horrors is that they are in C. I know C well, have used it almost daily around 25 years, used to love it, but now believe it should be used only by specially licensed people, or not at all. The reason is NOT that it allows low-level access, buffer overruns etc, but because its syntax and semantics are chock full of completely unnecessary pitfalls (many of which have unfortunately been inherited by its successors like C++, Java and Javascript). Don't believe? Quick, what does this totally valid fragment of C print:
typedef enum {val1, val2, val3} mytype;
mytype var = val2;
switch (var) {
val1:
puts("1"); break;
val2:
puts("2"); break;
val3:
puts("3"); break;
}
You can write horrible code in any language of your choice. Maybe the effects will be more or less dangerous depending on where it runs, but as the example showing getting OS commands from a web page well explains, you can create havoc in many different ways.
Any programming language should be only used by "specially licensed people" <G>. Heck, I should call a qualified electrician to change a plug, and everybody without the proper training should be allowed to write code? <G>
You can write horrible code in any language of your choice.
Sure, but some languages make it easier than others. But what I am really griping is about enabling (indeed, promoting) trivial mistakes. Forgetting "break" in C "switch" branches is one good example (and is known to have caused at least one widespread phone network outage!).. Allowing fall-through to the next branch is sometimes useful, but in most cases you don't want it. So the default action at the end of a branch should have been the opposite, and there should be some syntax to indicate the exceptional fall-through action.
Every language has its pitfalls if you don't master them enough well. It is true some older ones have designs more difficult to master, while some newer one are designed to sandbox the developer to try to avoid some mistakes (and pay him or her less...). But you can easily fire in your feet with any language. Take for example Python identation - if people don't follow code standards properly, and their editors are not set up properly, you may overlook some not correct identations that may lead to not correct execution paths.
I have the habit of writing immediately break statements when I write the skeleton of a switch one, exactly to avoid to forget one. Also, most IDEs able to run code analysis tools will usually warn of such issues - I don't feel a diminished programmer if I don't use a pure text editor with a command line interface - coding in the 1970s meant far smaller applications and code - I do expect in the XXI century to have machines help me to write and manage more complex code spotting mistakes I could make inadvertelntly.
FWIW, some of the stuff I have seen in perl makes C positively easy to read.
Seen too many people use both the above languages to write essentially obfuscated code as a job security methodology - making it a total pain for anyone else to decipher & them almost indispensable.
Whatever the language, obfuscated code is possible, code review by someone else before commit to your source code repository of choice is good practice (and obv. the reviewer should not be an obfuscation fan)
Are you complaining that someone forgot to put in 'case' or that enums start from zero?
In the first case, there are only around 30 or so reserved keywords in C. There are only two types of conditional statement (unless you count for/while). My point is that C is a pretty tiny language and if you use it for any amount of time you just know that switch and case go together. Why does it have to be 'case X:' and not just 'X:"? Because the latter is reserved as the syntax for defining a label so that you can jump ('goto') to a point later (and, yes, you can mix cases and regular labels--look up Zed's Device as a variant of Duff's Device). C is so small that you're expected to be able to make these kinds of distinction and always have them in your head.
In the second case, you can assign a constant value to one of the enumerated names and get var1=1, var2=2 and so on. But I don't really think you're complaining about that.
The "error" must be the missing "case" keywords. Counter-intuitively it is the experienced "C" programmer who would miss the error. Their brain would fill the gap with the expected keyword.
That was the conclusion of the BBC programme on the brain and "reality". The visual system is too slow to process all the information - so it fills in details with memories of what it expects from experience. Hence the common problem of seeing what you expect to see - and not seeing what you don't expect to see. The latter being the classic "gorilla" in plain sight that the brain appears to treat as an S.E.P (Someone Else's Problem).
A recent picture did the rounds online - find the panda in the array of snowmen.
http://www.buzzfeed.com/javiermoreno/here-are-all-the-hidden-panda-photos-people-have-been-going#.bvORNybne
The BBC programme also suggested that time appears to slow down in an emergency because the brain is having to pay more attention to actual visual detail - and that processing takes longer.
The "error" must be the missing "case" keywords.
Correct. I myself have made this kind of mistake years ago, and it took a very long time to find! (even started to suspect a compiler bug). Also have seen it a couple of times in code by others. The brain indeed tends to fill in the "case".
The only indication the compiler gave was some non-fatal warnings about unused labels, which tended to get lost in the noise of other minor warnings.
The comment is just too perfect and makes no explanation at all as to the mechanism or what the minor glitch is. It is also extremely unprofessional in tone. If such a serious situation can arise from such a small change is the whole design/architecture inappropriate? How do we know if some other bug may not cause a similar effect through a shared mechanism?
As for the prediction of the demise of a client company and the transfer of blame to the victim rather than those who wrote the software, it will appeal to those of us who code for a living, it makes us feel important and superior, but I suspect that a real story is being exaggerated or just made up.
I've often come across comments I left myself in my code, warning myself not to change something that I think will fix some problem, but will, in fact, have knock on effects. Usually as a result of trying that fix once before and finding out the hard way. For example, using "0" to represent a generic value or undefined case. I decided that it should, in fact, be NULL not 0, like in the other tables, but found that there were 6 other pages referencing that table that expected and required that undefined cases were represented by a 0. Or the note I left myself warning that there was a reason that the variable in this function had a special scope applied to it.
The most frustrating f***ups of recent days have come from developing code both at home and at work. Dreamweaver is a massive piece of shit, but I kind of like it. It has this odd quirk where if you have the files view set to "Remote", so you see the files on the server, and click to open the file, it opens the locally cached copy without checking if it varies from the remote (live) version first. So you invariably end up opening an old version without that tiny change you made a few days ago in the other location and reintroducing the old bug, but you've now overwritten the working version and you have to wait to get to the other machine in order to restore it, by which time you've forgotten the fix you made which was your whole reason for opening the file in the first place.
That's usually an issue when people use hardcoded valuesinstead of defining and using constants, and then ensure the proper constants are used everywhere.
if you defined the UNDEFINED constand as some value (i..e. 0) you can change it later (i.e. 0xFFFFFFFF) without having to chase all the code where you tested for 0. This a very simple example, but I've seen to many people avoiding using constants and types like enumerations which lead to better, sounder code, and more readable also, relying instead of "known" hardcoded values.
Sometimes I believe the refusal of some to use modern, powerful IDEs or code editors, and relying on simpler ones, lead them to write lazy code for lack of useful code navigation tools. And of course real programmers never use code analysis tools...
"The comment is just too perfect and makes no explanation at all as to the mechanism or what the minor glitch is."
It sounds to me like the result of some PHB dictating a kludge RIGHT NOW instead of re-writing a section of code to do a proper job.
> ...unprofessional in tone.
We had a problem where we were supposed to add functionality to a program a part of which a certain 'X' (not his real name) was supposed to deliver. We waited in vain for X to do his part. Finally one of us added the part X was supposed to do, plus the added functionality. Comment went (translated from German):
"This wouldn't be such a bloody mess had X, that lazy mongrel, done his job."
X worked for the customer we made the program for.
Program was shipped in source code. Customer shipped code to all his customers.
Apparently not a single person looked into the code for all those years, as no report came to us.
Surely that first item is nonsense.. what company would happily change a specific item of code at a customer's request?
They might change what a piece of code *does*, but changing a 1 to a 0 is non compliant, certainly not ISO whatever that number is, and the manager who said "yeah ok " would get fired straightaway.
Here 1 perhaps is a semaphore flag that means "Test that the data meeting valid accounting standards", things like sales x tax rate = salestax and so forth. Disabled (set 0) in development when processing produced no output at all with no visible reason, necessarily enabled at all times in the live system.
I agree that these stories probably are edited down to get us to the punch line faster.
The BBC series "The Brain with David Eagleman" explores how the brain interprets our surroundings. The theory is that most of the time it is painting in the visual detail from assumptions of past experience.
http://www.bbc.co.uk/iplayer/episode/b06y8hyr/the-brain-with-david-eagleman-1-what-is-reality
Is it just me that noticed the guy saying "Maybe you should employ some decent developers for once." is implying in saying that that they do not and have never employed any decent developers, immediately after saying he used to be one the developers?
So what he effectively ends up saying is, "This is what I want, I know what I'm talking about! Actually I'm an idiot!"
Did the guy requesting the change have multiple personality disorder or something? Personality #1 deduces that personality #2 will take over at some point and writes the comment to achieve some sort of victory over him? Did the guy wanting the change realise his mistake later and then travelled back in time to insert the comment when he was working for the original company?
Also, since each customer has his own version of the code, how does changing it for that customer affect the company writing the code? Surely even if they use the program themselves, they don't run a customer-customised version of it in house?
Too harsh you say?
The comment doesn't describe the specific consequences of a change because the author couldn't be arsed do any testing and find out. Hence lazy.
The comment doesn't describe the underlying cause, because the author is too stupid to analyse it. Hence buffoon.
Their fury at their own stupidity drove them to write that ridculous comment where they fling their faeces at some supposed future querier of their illusory authority.
The firm deserved to go under, whether because they didn't have the code reviewed, or because they did review the code and nevertheless didn't school the author.
My first impulse at some chunks of work is "What Were They Thinking?". Sometimes realize I was the one who wrote that, and ask "What Was I Thinking?". Often the answer is it was a workable solution, given the constraints at the time it was done. Sometimes things that worked then, do not work now after changes in scope or use; then I owe folk a beer. Even if it still works, I will shake my head and vow to never do crap like that again!
This post has been deleted by its author
A thousand years ago, we were approached by a client who insisted on writing some software in MS BASIC (yep, I did say a thousand years ago), but wanted us only to debug it.
Since I was the only one writing software at the time, I said either WE'LL write it, or nothing. I made it quite clear I wasn't going to do anyone else's debugging.
Sure you lose a job, but that one? I think we did well in dodging that bullet.
"I made it quite clear I wasn't going to do anyone else's debugging."
Long ago I divided programmers into rough classes of "developer" and "support" people. They appeared to be dependent on people's particular intrinsic human traits.
The "developer" person could really only debug their own code. If writing a patch for someone else's code they would produce an obvious "blister" that reflected the way they would have written the original code. It's logic and style would be that of the "developer". It often addressed the symptom and not the root cause - which sometimes caused another problem.
A "support" person could debug both their own and other people's code. When writing a patch it was seamless and indistinguishable from the original style. Sometimes it amounted to no more than a tweak that made the original code run smoothly. When developing their own projects they would include a lot of contingency handling.
Overall it seemed to be a case more of "nature" rather than "nurture".
One example was code that needed to be enhanced to support two devices of the same type - instead of the original one. After a few problems it finally worked - so no one queried how it was achieved.
Later on it needed to be extended to three devices. It was found that the "two" enhancement had been done by using a large sprinkling of branch decisions throughout the module to decide which device's control block was being addressed.
The enhancement to three (or more) devices restored the code to its original state by removing all these added branches. It then added a line of code to load the data base register with the address of the appropriate device's control block. The original designer's code had used that base register to determine the current device.
I have seen legacy code with things like:
True = true
do while True
if (something) then
True = false
end if
end while
if (True) then
'why doesn't this work anymore???
end if
and
(some code)
'remove this after 2012 june release
if (1=2) then...
only no one remembers if the thing was removed but not the comment, or even what the thing was that should have been removed, or if the if(1=2) is the removal, or if the if(1=2) is what was meant to be removed, so now both the comment and the if(1=2) block remain forever, just in case someone works out what the hell that code is meant to do, and finally removes whatever was meant to be removed.
Also,
'I have uncommented this line. it has been commented out for a while but I can't work out why. if anyone has a problem please let me know.
And one more:
call invert()
sub invert()
'WARNING: extid and extref have inverted meanings for the rest of this file!
tempid = extid
extid = extref
extref = tempid
end sub
yes. the warning is in the sub.
And even better
call SetBackEndValue(value, 1) '<=== DO NOT COPY THIS LINE, not ever! And especially not the '1'
I found it copied (complete with comment) in about 50 places...
Te sad thing is this 'SUCESS' code might actually work...
if it was a global variable and set in an interrupt routine.....buried in a totally unrelated section of code.
The horrors I have seen and been party to in 40 years.....
One of the greatest uses for this sort of programming was in the commodore 1541 disk drive
the BVI flag, if i remember correctly could be branched on which was an overflow condition
so
:loop NOP
Bvi loop
Then a situation the 6502 processor had an extra pin to allow this flag to be set externally......normally never used, but they used it as the BYTE clock for the read /write head, since it was way faster than setting & reading a port.........
IE 2 clock cycles as opposed to 8
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
