What Compsci textbooks don't tell you: Real world code sucks There’s a kind of cognitive dissonance in most people who’ve moved from the academic study of computer science to a job as a real-world software developer. The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is …
That's probably a case of bad management.
1 and 2 should be mentoring 3 to 10 on maintaining the production software and checking their solutions to problems. That way 3 to 10 will gradually become more and more competent.
The rest of their time they should develop/help develop the new projects.
If you want to have good work done, make your workplace a good place to work. Make it exciting, make your people learn a new thing every day. Give them the feeling that their work counts and that making better code is better.
This is another management problem. By not embedding code-review into normal production process, a problem like this is caused when ever someone tries to introduce code review from the ground up. Comment on someone's code and they'll regard it as either a personal attack. In such places managers are likely to be predominantly ignorant of coding. The best thing you can do is leave such a place.
PS: Code review is one of the few coding practices for which there is overwhelming evidence in favour. Aka - everyone should be doing it (or pairing).
>No. Have you heard of a concept called "code review"?
Graduate commits crappy code. Senior dev rejects the commit and tells grad why. Grad fixes it and learns.
Nowadays it's more like offshore dev submits crappy code, senior dev rejects it with detailed reasons, citing several examples and describing how to resolve.
Offshore dev resubmits with only the explicitly cited examples fixed, it's rejected again for issues with the 'fix' and citing explicitly each area that needs correcting.
Rinse and repeat until senior dev gets fed up and just accepts it or fixes it themselves!
Next week, the same dev submits code with exactly the same issues. Repeat ad-nauseum no one learning anything from the mistakes and reviews.
If the seniors aren't allowed to code themselves anymore it gets really painful, I've seen code reviews where everyone's so fed up the 4th/5th rejection just contains the correct code and just says paste this in
The first versions of the Mozilla suite and OpenOffice.org were basically formerly-proprietary projects which were suddenly Open Sourced. And they were riddled with schoolkid errors (OOo 1.x wouldn't even build on anything but 32 bits).
Knowing that there will be many strangers' eyes looking at your code tends to make you write it properly (and "properly" means -Wall doesn't say a dicky-bird); seeing someone else's bad code that could have been done better makes you think seriously about submitting a patch upstream. (Both these are examples of Hubris -- the third great virtue of a programmer).
We can only guess what other horrendous bodges lurk in other proprietary software.
"We can only guess what other horrendous bodges lurk in other proprietary software."
Well actually we can know, since we can work there. When I was a programmer I worked on a software package which long unsupported and unused which among many things printed receipts, bills and delivery notices. All of those contained VAT calculations. Well eventually it turned out that there was an error in the calculation under certain circumstances. The error was consistent in all the forms. So I looked for the routine to calculate the VAT found one and fixed the problem... Then there still was the same problem in another form. Turns out there were 3 (or so) versions of that code. 2 were just slightly modified copies of each other, while one was completely original. They all managed to have the same bug.
Then in another part of that project, probably the oldest part there were 2 forms which had to communicate some values. Now Delphi (yes this is old) does support variables and structures (called records) as well as events. However the developer chose to store the values into a local dBase table (I told you this is old), which was supposed to only contain one dataset, then the other window opened that table and you were able to edit it. (that's actually quite simple on Delphi) Of course when your program crashed when that table was open you had 2 datasets in there and it would fail.
Once we had an intern who was given the task to write an import program which should import a certain fairly complex file format into our databases. He did this by transforming the data in multiple steps (by itself not a bad idea) and used pre-created dBase tables for the intermediate results (bad idea, what if they aren't empty or are broken?) and every step used global variables. What made it unbearable was that those steps were semi-transparent to the user. So the user had to press several buttons after each other. Each press would send the computer working for quite a few minutes.
This is why you hire a project manager that has a background in the project's development.
Developers are very much in their own right artistic, some with licenses others not, yet modulated software development ... makes portability, troubleshooting and development much easier from the word 'Go'!
The output is only going to be as good as the input was in the first place! Never blame the developer, blame the culture of the **** for brains pressuring him to get something out the door!
There is only one way it's your code.
You develop it.
No one else ever maintains or updates it.
When you die all copies of the software will be erased and the source code destroyed (perhaps in viking funeral along with yourself).
Otherwise get over yourself and expect to have your code reviewed and you to review others.
And remember "Premature optimization is the root of all evil."
Me p**sed off. You bet.
I'm just gonna come out and say it....programming is not an art. And the thinking that it is, is a very big part of the problem.
It really, really annoys me whenI see a developer who refers to himself as an "engineer" one minute, and the next starts pontificating about how programming is an "art", and you have to "see the structure", and lots of waffle. This is one of the roots of the problem. Real engineers follow plans, methodologies, blueprints etc. The number of coders I see who think they are smarter than everyone else and try to do it their way, makes me pity the whole industry.
What programming really needs is a professional body that can dole out certifications and professional qualifications. So your a Python hacker? Have you passed the Institute of Programmer's exam? No. Get lost. Why do engineers, lawyers, accountants etc have professional bodies when programming can't. It would drive through standards that everyone will follow. Not like now, when you join a new company and you don't know what kind of weird methodologies they use. Every company has it's own idiosyncrasies when it comes to code. Why? It should be standardized with a professional body.
I know almost everyone would hate this idea, because it goes against some kind of hacker, free-to-do-what-I-want mentality that pervades the industry. But if standards are to rise it's going to happen eventually. Do 3/4 years at Uni then join a company which sponsors you to take your "Chartered Programmer" exam, while also working for them.
"and you have to "see the structure"" - easily done, just point me at the right header file. Oh, you didn't mean a literal struct. Okay, where's the internal documentation that shows how it fits together?
This is one of the other roots of the problem. People immersed in a project are the best ones to document it, but documentation is frequently erratic, incomplete, and out of date. Not just internal descriptions of "how this collection of crap fits together" but often user documentation. How often have you started to use a new program to find the documentation is hopeless or just plain missing? Where sometimes the only docs you see are COPYING.TXT (the GPL text)...
"Why do engineers, lawyers, accountants etc have professional bodies when programming can't. It would drive through standards that everyone will follow."
First, it would kill off home programming - for attaining such standards will probably out of budget for a person coding in their free time.
Second, it could stand to kill off open source - take your favourite part of Linux, are we to restrict code access to those who have qualifications only? What if a non-qualified person has a submission?
Third, it could stand to kill off software generally - we all know that software licences disclaim everything possible. We bitch about it, but as programmers we accept it because while our systems may crash from time to time, it's a safety net for our own code to be able to crash without the world ending. Obviously this is undesirable, but away from egotism, I understand that people are human and humans cock up from time to time. Do you think if software was written by accredited professionals (and no doubt more expensive because of it) that we'd expect to continue seeing "this product is supplied AS-IS" and the rest in the small print? Would you get on a plane if it had a sticker on the side that says that the manufacturer disclaims all liability for explosions or structure failure in flight (etc)?
"Every company has it's own idiosyncrasies when it comes to code. Why? It should be standardized with a professional body."
Yes, it should. And to make life so much easier we need to throw away all these stupid languages and just use one. If it can be expressed in Haskell or K or perl or any of the others mentioned in this article, it can be written in C.
Yes, I'm being sarcastic. There is no such thing as standardisation of coding practice when it's an entity that covers hundreds of related but very different cases. Examples:
* Kernel coding
* Large scale embedded devices (routers, video recorders, cash machines)
* Small scale embedded devices (bread makers, ECUs, pacemakers)
* Desktop publishers and word processors
* Fart apps
* Website back ends, maybe e-commerce stuff
* Educational/research systems; both the underlying system and the nerd-level stuff running on them
All of this (and more) is software engineering. There's no one standarisation that applies to all of them. Writing a kernel is very different to writing a fart app; and none of this "runs of a PC" sort of code has any relevance when you're hand-coding an entire system to run on an 8051 clone to power a breadmaker, where your code must be less than a few kilobytes and if you're lucky you might have 128 bytes of memory. But you absolutely cannot crash, not when you have a tiny oven turned on!
[FWIW - the breadmakers I've seen suck hard at proving the bread except in summer because they use fixed-duration timers instead of checking the ambient temperature; a cost/difficulty compromise perhaps?]
Do you not think this idea hasn't already been touted a dozen times before, and discarded as unworkable? Surely it is far better to foster the idea of good coding practice?
Here is an idea of my own, for college/uni programmers. You get to write something, and you get to maintain something previously written. What you get to maintain is what a person the year before you wrote; just as your creation will be given to somebody in the year following. This should hopefully demonstrate hands-on the need for clear concise code, where being obvious and unambiguous is far better than abusing the comma operator or burying stuff in a messy algorithm that relies absolutely upon the operator precedence of the language, or other "clever tricks" that only serve to demonstrate what a twat the author is. The person in college/uni can laugh at the poor code in their maintain project, and scratch their head over the stuff that makes no sense, until they have the realisation that their project could be treated in the exact same way by somebody else.
Another option, halfway through the year, swap projects. And you get marked up or down depending upon what the person now maintaining the code thinks of how it was written.
I think that engineering and art are essentially the same. An artist creates works to cause certain effects. For example he might arrange metal to cause fear in the person who looks at the work. An engineer could arrange metal to form a generator. Both use science to achieve means in a way which doesn't have any "best" way to solve a problem. Just look at the many different ways the problem of 'television' has been solved in the last 80 years. Both fields are highly influenced by what happens with their peers and in science.
The big difference is that artists typically have a portfolio. If you are a bad artist you won't get many jobs. In classical engineering there are certifications to pass. If you are a bad engineer you won't pass them.
Now with programming there is often neither widespread certification nor portfolios. Slowly portfolios start to pop open with open source software. Probably in a few years you will be unemployable unless you have some portfolio of open source software.
I think that engineering and art are essentially the same.
Really, only someone still at uni, a tenured prof in an isolated ivory tower or manager on an ISO 9000 trip thinks different.
This is why there is a book by Fred Brooks called "The Design of Design".
This is why Knuth titled his books "The Art of Computer Programming"
Then we have "Beautiful Code" ... "Programming Pearls" ...
Even Edsger Dijkstra who tried to light the fire of program proofs needed to pull artsy and sometimes impenetrable code from god knows where to fill his textbooks.
"Real engineers follow plans, methodologies, blueprints etc."
Hurrah for plans, methodologies and blueprints:
http://en.wikipedia.org/wiki/List_of_bridge_failures
What's your point? Software isn't any different from engineering or art - it is both functional and aesthetic. You spend an amount and standardise an amount and test an amount depending on your priorities, your budget and the risks to people and businesses using it. If failure in your software implies similar consequences to structural failure in a bridge , then the testing and commissioning of your software should be every bit as rigorous as for its physical analogue. Otherwise you are just over-engineering a white elephant.
"http://en.wikipedia.org/wiki/List_of_bridge_failures"
Perhaps you should study that list a little more carefully.
Software development has more in common with bridge building that you might think. One of the points made in Structured Programming (Mills, Linger & Witt) was that to do top down development your first release had to be a "proper top," a system that could be tested and bootstrap the testing of the rest of the functions. IOW functions to add records to a database (1st release, you can inspect the file contents with existing tools to check it works) get the ball rolling. Read and update functions can be deferred till the 2nd increment. Once you move away from database systems those decisions become more difficult to make.
typical software development works bottom up. It's like throwing bricks up in the air and hoping they will align well enough so that the structure will become self supporting before they all fall down.
Put that way is it any surprise large systems tend to have development issues?
The point about bridges is that there has been a steadily expanding body of theory to support their design. Study why bridges fall down. The main reason has shifted from "We don't know how to build them well enough not to" to bad (sometimes illegal) construction and/or materials and gross overloading. 160tonne vehicle on a bridge rated at 40 tonnes. WTF did they think was going to happen?.
In contrast there has been limited work in improving the odds of delivering large projects on time and budget. Perhaps more usefully has been the study of government IT project failures. Here shifting objectives, lack of senior management commitment and a desire for big bang rollout (no pilots and limited live testing) usually turn up in the top 5 ways to f**k up a project. I doubt private industry is that much different in any of these respects.
> "proper top," a system that could be tested and bootstrap the testing of the rest of the functions.
Yeah well, that really sounds like the "bottom" to me.
Redefine the words. Voilà, we are top down? Whatever keeps the project rolling and avoids the waterfall path into immediate obsolescence, I reckon. The goal is success any way you look at it.
You whats funny about this "most programmers have no clue what there doing" articles? They never seem to point you in the direction of what is "right". (And I don't disagree that there are many bad programmers)
I'm not a developer (well its not my title LOL), but that doesn't mean I don't have basic understanding of coding. Like other people in my situation, I learned programming on my own through books and tutorials online. I personally like python for write scripts, and quick and dirty programs for my self.
I don't plan to go into development (well I'd go back to school for it probably), but that doesn't mean that I haven't tried looking for articles, tutorials, and things on "proper programming". I'd prefer my programs are written correctly (since is my time and money) so that I have good code, but I haven't found any source that is an agree upon method of r doing anything regarding programming.
Dog + World can go online and learn the individual pieces of a programming language, I just haven't been able to find any good resources (Which could be do to my lack of programming knowledge) which I can trust.
And since "bad programmers" tend to search online and pull shit off it, I'd think the communities of programmers would tout this concept more.
The problem is that there is no single direction of "right". There are only principles you can choose to adopt. And there are good examples to follow as well as bad examples to avoid. Then depending on what you are trying to do you can choose the best way to do it.
Look at books like "The Art of Unix Programming" and look at what they propose. Those are pointers to right directions.
You could
A) Start studying Computer Science. It's not sufficient, but necessary to become a proper software engineer. Think of hash tables, parsers, complexity analysis and the like.
B) Join something like ACM or IEEE
C) Read books on Object-Oriented Analysis and Design, Use-case driven design. Very concrete approach in my opinion
D) Read books on Database Design such as Mr. Date's book.
E) Read IBM, HP, MS, Google technical reports/R&D magazines and try to understand them.
F) Develop toy projects
G) Take five years to become a C++ expert
All these activities will take years of your life for relatively little reward. But at one point you will be a master of your trade and you can give the idiots the middle finger then and now.
Well you should always broaden your approach. Don't be an OOP and database only person. Look at other approaches. Look into Lisp or Prolog. Look at Unix. Again there is no single good approach.
For me actually G) is the reason why I ignore C++. I have looked into it previously and never was able to figure out where the actual advantage is supposed to be. I mean I can have C++-like OOP in Pascal these days and it even handles objects with references and never implicitly copies an object.
Unfortunately the point where being a master of the trade matters may never come. Competency is not valued in real-life companies. You'll still end up having to deal with incompetent bosses believing they can do better than you.
There are many, many nasty things to say about C++, but in the hands of a Master (of the trade, not the academic thing), it can be used to create amazing things.
There was a time I would have called it "just a programming language like many others", but now I do think it deserves the massive investment in time, books and ripped out hair to become an expert. When you know more about the details of the memory hierarchy and about the dog-slowness of the new-operator (or equivalent in other languages), you will appreciate why you have this elaborate thing called C++.
AFAIK, you cannot allocate objects on the stack in Pascal, which is a major deficiency, performance-wise.
http://www.freepascal.org/docs-html/ref/refch6.html
Or maybe not, I am not an expert in Object Pascal.
According to the Language Shootout, C++ is leading in runtime and memory efficiency and that does indeed translate into usability, "user experience", into perfection of a product. I do think there is a strong reason why they used Objective C for the iphone, and not Java. With Java, you are just "good enough" from a usability point of view, with C variants you can be "perfect". I would take Pascal over Java any time, though.
And yes, managers know that truly competent people can give them the middle finger. They hate that fact, but they are rational enough to not fire these people as they would fire unskilled people. They bitch and moan, but in the end they have to somehow accept that the experienced C++ guy cannot be shoved around like the the Java greenhorn from uni.
And if you are truly pissed off, insult the boss to make him fire you. Then collect unemployment benefits for three months while you weigh your new opportunities. Not perfect, but tell me which job is perfect outside "being rich and stupid heir" ??
Picture of said heir.
"AFAIK, you cannot allocate objects on the stack in Pascal, which is a major deficiency, performance-wise."
Errr... Wouldn't this depend upon the ins and outs of the architecture upon which the language was running as to whether it preferred registers or stacking stuff?
That said, if we burn a hundred cycles, say, retrieving something that another language might have stacked for a cost of, say, 20 cycles... That's 80 cycles. On a 2+GHz processor. I'm just making up these numbers as I'm an ARM guy and I know very little about x86, suffice to say at today's clock speeds, I would imagine the choice of a good algorithm would make more impact than whether or not stuff can be stacked...
They never seem to point you in the direction of what is "right"
They do. Just remember that there is no such thing as quick and dirty; there's either clean and working or slow, dirty and horrid. http://allankelly.blogspot.co.uk/2009/09/quick-dirty-myth.html
All sorts of people have written good books on how to write good code. Such as:
Michael Feathers - Working Effectively with Legacy Code
Steve McConnell - Code Complete: A Practical Handbook of Software Construction
Steve Freeman and Nat Pryce - Growing Object-Oriented Software, Guided by Tests
Martin Fowler et al - Refactoring: Improving the Design of Existing Code
Bob Martin - Clean Code
Bob Martin - Agile Principles, Patterns and Practices in C#
Bob Martin - Agile Software Development, Principles, Patterns, and Practices
Neal Ford - The Practical Programmer
Furthermore there are now lots of free courses teaching programming on the internet at places like coursera, Udacity, edX. Someone's even written an aggregator for you: http://www.class-central.com/
In my experience people fixing code could be divided into "developer" and "supporter" types.
The "developer" mentality always wanted to impose their own design. This resulted in blisters that stood out like a sore thumb - and often introduced secondary problems.
The "support" mentality was to spend a long time understanding how the original code worked - then applying a minimal tweak that was indistinguishable from the original coding.
One piece of code had been enhanced to support two instances of a structure. The enhancement "developer" had written numerous inline tests to keep determining which of the two control structures was in use. Later, when multiple instances were needed, a "support" person ripped out all those binary tests - and added one initial line which set the base register to point to the appropriate control structure.
The biggest pitfall is to notice, in passing, something is "wrong" and immediately fix it - and the law of unintended consequences comes into play.
The first rule of documentation/comments is that the more precise the detail - the more likely it is to now be wrong. Useful comments are the ones that explain why an "obvious" alternative/simpler approach had been tried and didn't work.
Sometimes you are charged with "improving performance" and that means redoing lots of code and obviously introducing new bugs. And new bugfixes for that. It sometimes means changing the architecture in some ways.
But yes, every change is a risk that should be weighed against benefits. Changes for prettiness are too expensive and too dangerous.
The comment “nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is,” goes to the root of the problem.. because it is just not true text-books often have coding errors & many examples are banal.
Students that are taught to ignore {transactions, Exceptions, Recovery, Logging, instrumentation, performance, scalability, maintainability} are not being taught to “focus on the algorithm” they are being taught to be sloppy. Poor coding tuition is compounded by poor design tuition (e.g. Manager is a specialization of Employee, or GoF state-pattern). The problem is that whilst the quality of tuition is variable, different institutions are variable in different ways.. and students think they’re brilliant.
Many systems (particularly in finance) are so woeful because trainees (in the art of software engineering) have no real training in quality engineering; and resort to hacks to get through. Meanwhile an earlier generation who didn’t graduate to quality professional before moved into management are directing, but are afraid to tell sponsors how long development really takes.. because they don’t know. You only need to do 1 or 2 well engineered systems to know that good design saves time & modeling really is free.
There is hope: some practitioners are excellent; tools are getting better; frameworks are getting better; platforms are standardizing.
Sure an awful lot of real world code sucks, but some of it is quite beautiful!
A beeelion years ago, I did a sort of internship at a place where there were keyboard monkeys writing code to specification. I'm not being rude, they called themselves that too. Because Specification Was King and the managers and such who made the specification expected it to be followed exactly. To give an idea, multiply an integer by two. A coder will think that if it is always an integer (yes) and always by two (yes), a left shift would do it. But no, the specification said multiply so a multipication function was called (before CPUs had this sort of stuff onboard) and a result returned many many clock cycles later.
There were many more examples of people who didn't understand the underlying system expecting a spec to be followed to the letter; it was particularly fun when the spec contradicted itself (which it did frequently in the parts about "handling events" (they meant interrupts)), not to mention controversies such as the system blowing up on the first interrupt because the ISR wasn't cleared because the spec writers didn't know there was one and the coders (who knew) followed the spec (intentionally).
Maybe this was Programmer Hell? I don't know. It's why I code as a hobby but dropped any ambition to do it professionally. I enjoy what I do, and the above sounded as far from enjoyable as possible without actual physical harm being involved.
I have never worked in banking but I did work in a medical device company that had a lot of software developers leave for the banking industry. Several cam back becaus ethe complained that the technical demands of software in finance was vry very low, the level of skill of other developers especially senior ones wa satrocious and they were bored. The pay was of course much higher.
One specific colleague said that he was taken aside by his manager for producing software too quickly to too high a standard. He had spoken to the end users, written and developed a requirmenst specification, reviewed it with the users, prototyped the code, evaluated itwith ethe user and devloped an automatiuc test suite and was about to deliver it. His manager told him to stop work for two months otherwise it would cause a problem in setting an expectation for the amount of time and effort required to prodcue similar applications.
When interviewing staff it is rare t meet a competent long term developer who has worke din teh finance sector but they have extraoridnarily high salary expectations. This is a big issue if you find the need to develop using paltofrms and tools popular in finance.
I think the reason is that within the banking culture generally there is a very high level of pay unrelated to skill and ability. The people managing these organisations like to believe that pay level is related to skill and expertise because that makes them feel comfortable about their own very high renumeration, unfortunately recrutiment of staff on this basis has lead to an organisation and culture of highly paid incompetence.
I am sure theer are some highly skilled developers in the banking world but...
This one I like to repost again and again (Google reveals: more often than I can remember. Frak you, Google!)
"Social Impact of Information System Failures"
IEEE Computer, June 2009 (Vol 42. Issue 6, pages 58-65); Tamai, T.
The case of Mizuho Securities versus the Tokyo Stock Exchange (TSE) is archived in the 12 December 2005 issue of the Risks Digest, and additional information can be obtained from sources such as the Times and the New York Times, among others.
The incident started with the mistyping of an order to sell a share of J-Com, a start-up recruiting company, on the day its shares were first offered to the public. An employee at Mizuho Securities, intending to sell one share at 610,000 yen, mistakenly typed an order to sell 610,000 shares at 1 yen.
What happened after that was beyond imagination. The order went through and was accepted by the Tokyo Stock Exchange Order System. Mizuho noticed the blunder and tried to withdraw the order, but the cancel command failed repeatedly. Thus, it was obliged to start buying back the shares itself to cut the loss. In the end, Mizuho’s total loss amounted to 40 billion yen ($225 million). Four days later, TSE called a news conference and admitted that the cancel command issued by Mizuho failed because of a program error in the TSE system. Mizuho demanded compensation for the loss, but TSE refused. Then, Mizuho sued TSE for damages.
....We then segue into design horror....
The part of the system that handles order cancellation appears to have low modularity. The logic in part B of the flowchart made a wrong judgment because the information telling it that the target order had induced the reverse special quote had been temporarily written on the Stock Brand DB by the order matching module and had already been cleared. This implies an accidental module coupling between the order matching and order cancelling modules. The order cancellation module appears to have insufficient cohesion as different functions are overloaded. It is not clear how the tasks of searching the target order to be canceled, determining cancellability, executing cancellation, and updating the database are this module’s responsibility.
etc. etc.
There is a grabbable copy on the Internets, so no need to pay abject obeisance to the IEEE paywall.
The saying at my workplace is that our IT motto is "World-Class For Free". The current reason upper management gives for there being no money to hire enough people to maintain the system, let alone upgrade it, is that the users on the business side don't complain enough about it. Has anyone else ever wished for less forbearance from their users...?
Yes, my resume is in active circulation!
So, we've had a bunch of comments here generally complaining about the crapness of other people's code, about how crap most programmers are and about the crap state of programming in general.
So please tell me: where are all the crap programmers? Have a look in the mirror..
Most programmers think they are above average. Just saying...
Absolutely. That's why you should look at the ones who believe they are average and admit they have huge gaps in their knowledge. Look at what they have done, maybe give them a few puzzles to solve like giving them a "hello world" program with an obvious buffer overrun inside and see if they'll find it.
Like give them this program and ask them what it does:
#include <stdio.h>
char *s[10];
void main() {
printf("Enter your name: ");
scanf("%s",s);
printf("Hello ");
printf(s);
}
Nobody will find _all_ the bugs, but it gives you valuable insights into how the programmer thinks.
1.) You are declaring an array of char* pointers, not an array of chars
2.) main has to return something and accept some arguments (argc and argv), IIRC
3.) scanf gets a bad argument (expects char* not char**) and will make a buffer overflow if the user wants to
4.) printf(s) will generate another buffer overflow mess if the user enters something like "jdfhj%sdfkdfkjdkfj"
5.) missing "return 1"
I would say your quiz was rather "average". Have seen much, much more nasty code samples.
"The most common reason for the existence of bad software is bad programmers"
There are a lot of them that's true. But they can be guided by one good senior dev given the time to do code reviews. In my experience, the reason for bad software is vague requirements and impossible deadlines caused by salesmen telling pure lies.
"For the record, however, I don’t think I’ve ever seen anyone go back and clean up a quick-and-dirty fix"
Then you yourself are a bad programmer. Or one of those fly by night contractors. Personally I will very often replace dirty with clean when a new requirement would otherwise require to layer on some more quick and dirty.
1)The users always know what they are doing.
2)They never make a mistake when they enter their decisions into the system.
Anyone who writes textbooks which ignores this is definitely going to be in for a real surprise.
You can design software that's small _and_ flexible.
Imagine you had a program calculating magnetic field strengths from a vector input of currents. If you just make it a "filter" taking text and giving text, you can just bail out on the first problem, the user can then edit the input and run it again. If the user is not satisfied he can also just edit the input and run it again.
Now if you store the data in databases it's not as simple. You need to provide an interface to change that database. You need to make sure the output database is in a clean state when you start. This may seem trivial in this case (just delete all records), but imagine importing data into a database from another source. If you merge that data directly you will need to deal with impartial merges because of input errors.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
