Programming Mistakes To Avoid 394
snydeq writes "InfoWorld's Peter Wayner outlines some of the most common programming mistakes and how to avoid them. 'Certain programming practices send the majority of developers reaching for their hair upon opening a file that has been exhibiting too much "character." Spend some time in a bar near any tech company, and you'll hear the howls: Why did the programmer use that antiquated structure? Where was the mechanism for defending against attacks from the Web? Wasn't any thought given to what a noob would do with the program?' Wayner writes. From playing it fast and loose, to delegating too much to frameworks, to relying too heavily on magic boxes, to overdetermining the user experience — each programming pitfall is accompanied by its opposing pair, lending further proof that 'programming may in fact be transforming into an art, one that requires a skilled hand and a creative mind to achieve a happy medium between problematic extremes.'"
What common mistakes do you frequently have to deal with?
Printable version - All on one page (Score:5, Informative)
And now for the printable version with all the tips on one page:
http://infoworld.com/print/145292 [infoworld.com]
Y
accompanied by its opposing pair (Score:4, Informative)
Doesn't mistake number 2 contradict number 1? Or am I missing something?
Yup. FTA:
Below you will find the most common programming pitfalls, each of which is accompanied by its opposing pair, lending further proof that programming may in fact be transforming into an art -- ...
Re:"Common" mistakes (Score:5, Informative)
UK doctors leave 722 objects inside patients in 1 year [sify.com]
Re:#1 - Not managing the pointers and memory yours (Score:5, Informative)
#1 - If you are a programmer, BE A PROGRAMMER and manage the pointers and memory allocations yourself. Garbage collection is for little boys. Men deal with it on their own with techniques that work and are efficient.
So mega-strongly disagree dude. Not saying you shouldn't do heavy lifting when necessary -- just that you should only do it when necessary. Don't re-invent the wheel every time. Frameworks exist that do work for you for a reason. Chose your frameworks well, understand them in depth, and you can do good things. If you "start from the first principles" every time, you end up with a humongous fucking surface of new code -- which is bound to have a nasty bug or three. It comes down to choosing the best tools for the job.
#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.
True dat. Lots security pitfalls here too -- not just garden variety bugs.
#3 - Use descriptive variable names
So true. Corollary to that: because a variable name is descriptive, don't make wanton assumptions about it.
#4 - you shouldn't be allowed to program anything new until you've been a maintenance programmer for a few years and seen the crap code that others puke into the world. Your crap code stinks too, BTW.
I'd modify this to say "always, always, always have a peer-review process". Junior devs are prevented from checking in crap because it gets caught by senior devs. The junior devs also learn quality habits from reviewing senior devs' code. Multiple reviewers is always a good thing. Review your design among the entire team before anyone writes a single line of code. Remember to keep security in mind when reviewing code. Use static analyzers when you're done with the "human" aspect of the review. Apply every imaginable quality bar to your code, and only check it in once it has passed scrutiny.
Re:Pointer typedefs (Score:4, Informative)
Pointer typedefs were a bad idea in the 1980s. They're just terrible today. One pet peeve of mine is this:
typedef struct _FOO { int Blah; } FOO, *PFOO;
void
SomeFunction(const PFOO);
That const doesn't do what you think it does. There was never a good reason to use pointer typedefs. There is certainly no good reason to do so today. Just say no. If your coding convention disagrees, damn the coding convention.
Care to elaborate (on pointer typedefs and the CONST PFOO usage)? Honest question from someone that hasn't touched a C/C++ for the last 12 years and is trying to clear the cob webs.
The pointer is constant... not what it "points to" and the typedef "hides" that
Re:Pointer typedefs (Score:5, Informative)
Re:do x but not too much! (Score:5, Informative)
"The whole lot is full of contradictions"
No, it isn't. It goes "don't do that... but don't fall in the other extreme".
That's on line with his central idea that programming is "an art, one that requires a skilled hand and a creative mind to achieve a happy medium between problematic extremes".
Re:"Common" mistakes (Score:5, Informative)
UK doctors leave 722 objects inside patients in 1 year
That's actually not the fault of the doctor, except in the "it's his O.R. so anything that happens in it is his responsibility" sense.
The "circulating" tech or nurse is the non-sterile person who fetches stuff out of cabinets, opens packages, and makes notes like "opened a package of 10 sponges" (typically by making a row of checkmarks on a pre-printed form).
The "scrub" tech or nurse is the sterile-gowned-and-gloved person standing next to the surgeon who passes instruments, puts knife blades on the scalpel handles, loads the needle drivers, and keeps track of the gazillion tiny pieces to everything. There are so many removable parts because everything has to be able to be broken down into pieces small enough to clean, sterilize, and package, and part of preparing for a surgery is re-assembling all the stuff so it'll be ready if the surgeon needs it.
The circulators and scrubs work together as a team. The circulator will say stuff like "here's the 10-pack of sponges", and the scrub will relay messages like "I counted them and there are 10 sponges there" or "I opened a package of 5 needles and there are actually 5 needles". The circulator will check off "10 sponges" or "5 needles" or "bolt and wingnut for the retractor" to build a list of everything that has been opened in the room which could possibly fit inside someone.
At some point, the surgeon will say, "OK, I'm getting ready to close". At this point, "the count" begins. The circulator will ask how many needles the scrub has, and the scrub will answer (including the one that the surgeon is actively using at that moment). If the counts match, the circulator will check off "needles" and move on to sponges, or knife blades, or wingnuts, or whatever else they'd opened earlier. When they're done, the circulator will announce that the count is correct and the surgeon will finish closing, which they're already well into by this point because the count is pretty much always correct.
Except when it's not.
The biggest ass-chewing I've ever received in my life was when I was in the Navy and scrubbing for some captain and we couldn't reconcile the number of sponges. One was missing, and the presumption was that it was still inside the patient. After a few minutes of pissed-off-high-ranking-officer-screaming, they wheeled the patient out anyway and prepared to X-ray them to find the missing sponge. Ideally, everyone would stop what they're doing and stand around while we searched, but the realities of surgery are that the anesthesiologist plans the sleeping and waking cycles and you really don't want to start putting them back down into deep anesthesia or keep them down longer than absolutely necessary.
So, we tore the room apart. We moved cabinets. We dismantled the surgical table. We dumped all the trash - clean and hazardous - onto the floor to dig through it. The captain would periodically stick his head in to ask why the hell we hadn't found the f'ing sponge yet and what the hell was wrong with us and did we know whether this was a courtmarshalling offense.
Finally, the anesthesia resident - a much lower-ranking officer fresh from med school - sheepishly asked what a sponge looked like. Turns out, one had fallen on the floor during the case and he'd "helped" us keep the room clean by throwing it in the anesthesia trash that he was responsible for.
As an enlisted person, that was the one time in my career that I actually yelled at an officer (who had the good grace to accept that he'd screwed up and had it coming to him). He went and told the surgeon what happened, X-rays were avoided, courtmarshalls were cancelled, and we scrubbed the room down from ceiling to floor because we'd strewn bloody trash all over the place while digging through it.
Anyway, so yeah. The counts are ultimately the responsibility of the surgeon, but the surgeon is not the person who actually does the counting - nor could they possibly be expected to without dramatically lengthening the time a patient would have to spend under anesthesia. Behind every object left inside a patient is a scrub and/or circulator who accidentally miscounted or who lied on the count sheet to hide their screwup.