Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Programming Mistakes To Avoid

Soulskill posted more than 3 years ago | from the livin'-on-the-edge-cases dept.

Programming 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?

cancel ×

394 comments

Missing out on first post (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34471350)

I hate it when that happens.

Printable version - All on one page (5, Informative)

Yuioup (452151) | more than 3 years ago | (#34471354)

And now for the printable version with all the tips on one page:

http://infoworld.com/print/145292 [infoworld.com]

Y

Re:Printable version - All on one page (1)

Bobakitoo (1814374) | more than 3 years ago | (#34471618)

It is the first time i bother to rtfa. Thank you very much, it been a pleasing experience.

Re:Printable version - All on one page (4, Insightful)

CountBrass (590228) | more than 3 years ago | (#34471766)

'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.' Bullshit. Programming has always been an art that required skill and a creative mind. The only people who have claimed otherwise have been managers, who would prefer all techies were interchangable cogs, and crap programmers: the gimps and muppets of our trade.

Re:Printable version - All on one page (4, Insightful)

commodore64_love (1445365) | more than 3 years ago | (#34471818)

>>>Programming has always been an art that required skill and a creative mind

plus logical thinking (like the machine you're programming). It always surprised me when my Professor/Director of Engineering said programming should not be considered a "science" or "engineering". He said they were the equivalent of bus drivers - just human beings running a machine.

At first I thought, 'Well maybe he has a point' but no not really. Driving a machine is a skill that can be learned in a day or two. Programming a machine requires years - the same amount of time needed to learn any engineering discipline.

 

Re:Printable version - All on one page (1)

ByOhTek (1181381) | more than 3 years ago | (#34472034)

And a lot of graphic/physical artist. I've seen many who do graphic arts, drawing and painting, who seems to think that if you are in any computer programming or science field, you have no creativity.

Re:Printable version - All on one page (-1, Flamebait)

commodore64_love (1445365) | more than 3 years ago | (#34471776)

Thus you've taken their labor w/o paying for it (i.e. not viewing the ads)
Uh oh - here come the (-1) mods but I don't care: I speak truth to power.
I think people are entitled to get paid for their hours.

Re:Printable version - All on one page (3, Insightful)

Bobakitoo (1814374) | more than 3 years ago | (#34471896)

If you would have care to check the link, you would have see the IBM advertisment on the side. Also print layout is a feature of the site, OP did not invented it or hacked it in. Or maybe it is you that run ads-blocker and steal their labor? If you get mod down it will be only because you speak bullshit.

Re:Printable version - All on one page (1)

poetmatt (793785) | more than 3 years ago | (#34472052)

what advertisement? I haven't seen ads on websites in years between my hosts file and adblock.

Re:Printable version - All on one page (1)

oneandoneis2 (777721) | more than 3 years ago | (#34471994)

Funny, that: When I view the link to the printable version, I get an ad in it.
Did you just not bother to look, or did you forget to turn off your adblock before looking? :)

Tests, Manual, Support by programmer. (5, Insightful)

Barryke (772876) | more than 3 years ago | (#34471378)

What common mistakes do you frequently have to deal with?
- Software only tested by programmer.
- Manual only written by programmer.
- Support can't do a day without programmer.

A good programmer should know when to delegate. Or their boss should. Depends on office culture perhaps.

Re:Tests, Manual, Support by programmer. (1)

sensei moreh (868829) | more than 3 years ago | (#34471602)

What common mistakes do you frequently have to deal with? - Software only tested by programmer. - Manual only written by programmer.

My mid-1980s solution: I wrote the code and handed it to my partner with brief usage instructions. He ran the code, making sure it did what it was supposed to and that it didn't break when entering nonsense (and came back to me with a few areas that needed fixing), and wrote the manual. I'm sure it worked out better than if I had written the manual

Re:Tests, Manual, Support by programmer. (1)

drinkypoo (153816) | more than 3 years ago | (#34471698)

One modern solution is to write both from the specifications, then run the program according to the documentation to attempt to generate the screen shots...

Programming Mistakes To Avoid... (3, Funny)

Anonymous Coward | more than 3 years ago | (#34471390)

...just try to avoid errors and you should be set.

Maintaining code by others are always a nightmare (4, Interesting)

TheViciousOverWind (649139) | more than 3 years ago | (#34471398)

Until you spend enough time with it, to learn why the original programmer did as he did.

As I see it, most projects start out with a good structure and the best of intentions, and then comes deadlines and the developer having to juggle several projects at once, and then a shortcut is taken here, then there. And suddenly you end up with a non-documented project where the only person that knows how it works is the original developer.

There will however always be BAD code by bad programmers. I've taken over Java progress where everything was OOP'ed into hell (as in a bazillion classes more than was needed for the application) and PHP projects which should be OOP'ed but consisted of about 500 files that included each other in a huge confusing net.
I've also had to take over projects where the original developer was using new technology because he thought it would be fun (at the expense of the customer). Having a huge website in PHP/MySQL and then having crucial parts of it in Ruby/PostreSQL is just a maintenance nightmare.

Re:Maintaining code by others are always a nightma (0)

Anonymous Coward | more than 3 years ago | (#34471510)

It gets worse when BAD programmers, think they are good.

Re:Maintaining code by others are always a nightma (2)

YeeHaW_Jelte (451855) | more than 3 years ago | (#34471748)

All true. My personal favorites are larger, long running projects where all of the above is true and all kinds of undocumented business logic is embedded in the code making a rewrite unfeasable and you have to decide which part of the code is outright sloppy or bad, which parts are feasable and which parts aren't actually being used anymore. Top that off with the original developers being unavailable (either dead or fleeing) and you'd be painting a pretty accurate run-of-the-mill software enviroment.

Re:Maintaining code by others are always a nightma (5, Insightful)

BiggerIsBetter (682164) | more than 3 years ago | (#34471842)

There will however always be BAD code by bad programmers. I've taken over Java progress where everything was OOP'ed into hell (as in a bazillion classes more than was needed for the application) and PHP projects which should be OOP'ed but consisted of about 500 files that included each other in a huge confusing net.

I see this one as a lack-of-experience problem. People have good intentions and want to build scalable, extensible, maintainable code. This is good. Unfortunately however, they're wrong. The apps they're building are small irregardless of the amount of thought they put into them, and they won't have to scale and extend the way they think they might - you don't need interfaces and impls and arbitrary inheritance for everything when the webapp is 4 screens of Spring WebFlow! Sure, if you're building something that warrants it, this is the way to go, but most of aren't building apps that big or flexible. It seems to take time to learn this, and to know when to apply the patterns and when to just build it.

As a smarter man than I once said, Make things as simple as possible, but no simpler. If you do that, your code will work, it'll be understandable by the next guy, and you'll have a fighting chance of meeting your deadlines.

Mistake #13 (1)

Anonymous Coward | more than 3 years ago | (#34471404)

Equating web programming with all programming.

Re:Mistake #13 (1)

digitig (1056110) | more than 3 years ago | (#34471526)

I thought the article was going to fall into that trap, but it avoided it. Some of the examples were web programs, but the overall points were widely applicable.

Re:Mistake #13 (0)

Anonymous Coward | more than 3 years ago | (#34471558)

Lol. For those who can't be bothered to read the article, a quick summary:
I write GUI in Java for the web. Let me talk about some problems I've encountered with web development in java. Please buy my book on databases.

Only one programming mistake to avoid: (1)

Harold Halloway (1047486) | more than 3 years ago | (#34471416)

Learing how to do it in the first place.

Re:Only one programming mistake to avoid: (1)

Harold Halloway (1047486) | more than 3 years ago | (#34471428)

Or even 'learning'.

Tchoh.

do x but not too much! (1)

0111 1110 (518466) | more than 3 years ago | (#34471420)

Programming mistake No. 1: Playing it fast and loose
Failing to shore up the basics is the easiest way to undercut your code. Often this means overlooking how arbitrary user behavior will affect your program. Will the input of a zero find its way into a division operation? Will submitted text be the right length? Have date formats been vetted? Is the username verified against the database? Mistakes in the smallest places cause software to fail.

Fair enough. So debug while you code. Seems like good advice.

Programming mistake No. 2: Overcommitting to details
On the flip side, overly buttoned-up software can slow to a crawl. Checking a few null pointers may not make much difference, but some software is written to be like an obsessive-compulsive who must check that the doors are locked again and again so that sleep never comes.

Doesn't mistake number 2 contradict number 1? Or am I missing something? I guess he's saying debug while you code, but not too much. After reading the rest I see that that was his algorithm for writing the whole article. Rule 1: do x; Rule 2: But not too much! I didn't really find the article all that useful.

All programming should be assembly language programming anyway and a lot of his rules don't seem to apply to assembly language programming. Remember rules aren't necessary when you are a programming god who only codes directly in machine opcodes. Even assemblers are for weenies. Man up and become one with the machine!

accompanied by its opposing pair (3, Informative)

Barryke (772876) | more than 3 years ago | (#34471484)

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:do x but not too much! (5, Insightful)

Chrisq (894406) | more than 3 years ago | (#34471492)

Doesn't mistake number 2 contradict number 1? Or am I missing something?

The whole lot is full of contradictions:

4: Delegating too much to frameworks 8: Reinventing the wheel
9: Opening up too much to the user 10: Overdetermining the user experience
5: Trusting the client 6: Not trusting the client enough

I think that there is a meta-message, akin to Buddha's middle way. Don't take any rule to extremes.

Re:do x but not too much! (4, Informative)

turbidostato (878842) | more than 3 years ago | (#34471996)

"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:do x but not too much! (1)

syousef (465911) | more than 3 years ago | (#34472030)

Doesn't mistake number 2 contradict number 1? Or am I missing something?

The whole lot is full of contradictions:
4: Delegating too much to frameworks 8: Reinventing the wheel
9: Opening up too much to the user 10: Overdetermining the user experience
5: Trusting the client 6: Not trusting the client enough
I think that there is a meta-message, akin to Buddha's middle way. Don't take any rule to extremes.

Confucious say: This one skitzo mutherfucker

Re:do x but not too much! (1)

Okind (556066) | more than 3 years ago | (#34471496)

Programming mistake No. 1: Playing it fast and loose.

Fair enough. So debug while you code. Seems like good advice.

Programming mistake No. 2: Overcommitting to details.

Doesn't mistake number 2 contradict number 1?

Yes it does. The difficult part is knowing the balance, as indicated by the summary: "programming may in fact be transforming into an art, one that requires a skilled hand and a creative mind [...]"

Re:do x but not too much! (2)

BiggerIsBetter (682164) | more than 3 years ago | (#34471894)

Yes it does. The difficult part is knowing the balance, as indicated by the summary: "programming may in fact be transforming into an art, one that requires a skilled hand and a creative mind [...]"

Personally, I believe we'd be better off it professional programming transformed from an art into an engineering discipline. IMHO, building robust and efficient applications should be a boring and repetitive exercise in design and implementation of prescribed design patterns... maybe then we'd turn our industry's abysmal success rates around.

Re:do x but not too much! (1)

Okind (556066) | more than 3 years ago | (#34471976)

Personally, I believe we'd be better off it professional programming transformed from an art into an engineering discipline. IMHO, building robust and efficient applications should be a boring and repetitive exercise in design and implementation of prescribed design patterns... maybe then we'd turn our industry's abysmal success rates around.

A good point. Sadly, I've yet to come across an easy to understand development process that doesn't pin down way too much. We're doing Agile for a reason.

Re:do x but not too much! (2)

icebraining (1313345) | more than 3 years ago | (#34471500)

Fair enough. So debug while you code. Seems like good advice.

s/debug/test/

Missing from the article (5, Insightful)

eagleyes (737026) | more than 3 years ago | (#34471438)

The most common programming mistake to avoid: Reading badly written articles about "what programming mistakes to avoid".

Re:Missing from the article (1)

Anonymous Coward | more than 3 years ago | (#34471486)

Or just avoid any of the _____World network. 95% of the articles seem like click trolling trite to me.

#1 - Not managing the pointers and memory yourself (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#34471482)

#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.

#2 - Initialize all variables to known values. int i; doesn't cut it. int i=0; does.

#3 - Use descriptive variable names

#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.

Re:#1 - Not managing the pointers and memory yours (1)

icebraining (1313345) | more than 3 years ago | (#34471528)

Unless you're coding in machine opcodes like a previous poster suggested, you're already losing some optimization potential by relying on the compiler/interpreter to do it for you. Even in C you're relying heavily on machine generated code. So why is garbage collection so bad?

It seems to me like the structured programming debate all over again.

Re:#1 - Not managing the pointers and memory yours (1)

MadKeithV (102058) | more than 3 years ago | (#34471626)

So why is garbage collection so bad?

'cause it tends to flush predictability right down the toilet. When is the garbage collector going to swing around to do its thing? Are you *sure* it's going to be when it has enough time to do so? Or is it going to pick exactly the wrong moment? Am I going to run out of memory at an awkward time triggering a collection of thousands of objects I haven't used in ages?

Yes, all of these have perfectly valid workarounds.
However, then you are right back to knowing exactly what your compiler and environment are going to do, and sometimes even holding its hand. Manually triggering a collection isn't all that different from handling memory management yourself.

The Right Tool for the Right Job sometimes is low level. And by the way, many great programmers know quite well what the compiler will do with particular important bits of code, and if they do not, will invoke the compiler to generate assembly or intermediate-language code to be sure. Yes, in garbage-collected languages too, I've used ILDASM quite a bit to know what C#/.NET was doing, exactly.

Re:#1 - Not managing the pointers and memory yours (5, Informative)

dhavleak (912889) | more than 3 years ago | (#34471652)

#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.

Mistakes? (2)

thermal_7 (929308) | more than 3 years ago | (#34471488)

I very rarely see programming mistakes. There seems to be 2 kinds of programmers.

- Those who care about what they do and try hard.
- Those who don't care about what they do and don't try hard

The later write terrible code, but it is just because they are either lazy or aren't suited to the profession and can't get enthused. Very rarely do you see someone who cares about there work make a big mistake (and if so they are probably just starting out).

Re:Mistakes? (5, Funny)

Chrisq (894406) | more than 3 years ago | (#34471642)

I very rarely see programming mistakes.

Neither do the bad programmers!

Re:Mistakes? (0)

Anonymous Coward | more than 3 years ago | (#34471854)

<quote><p>who cares about there work</p></quote>

there work?
Their work, surely.

I do hope you are not a programmer with THAT lack of attention to detail! ;-)

Re:Mistakes? (0)

Anonymous Coward | more than 3 years ago | (#34471908)

while we're talking about getting it right..

s/there/their/

Re:Mistakes? (1)

syousef (465911) | more than 3 years ago | (#34472036)

Very rarely do you see someone who cares about there work make a big mistake (and if so they are probably just starting out).

Really? I see it all the time from very intelligent but inexperienced programmers. I've seen a few spin their wheels and end up depressed about their whole job.

Programming Mistake #0 (4, Insightful)

Voulnet (1630793) | more than 3 years ago | (#34471504)

Programming mistake #0: Believing that your computer degree (Computer Engineering or Computer Science alike) automatically puts your code in a high level of quality.

Not to bring any academia vs industry argument, but many students miss the idea of a Computer degree with programming courses in it: The degree intentionally doesn't go to details because it needs to give you a background into a broader set of subjects. Industry needs one to be very attentive to details in that one thing he's doing at the moment.

Re:Programming Mistake #0 (5, Insightful)

digitig (1056110) | more than 3 years ago | (#34471546)

True enough. And since every rule has to have a complement, 0a: Assuming that you don't need to learn any of that theory: algorithms, data structures, normalisation and so on

"Common" mistakes (4, Insightful)

Alex Belits (437) | more than 3 years ago | (#34471506)

The only common mistake I see is not firing the programmer who makes any of those "common" mistakes. There is absolutely no reason for any of this shit to be "common" unless "programmers" who make them are uneducated dumbasses who should never be allowed anywhere near software development.

Now, please, give me the list of "common mistakes" made by surgeons and aircraft engineers, and compare them with this list of amateurish crap.

Re:"Common" mistakes (5, Informative)

icebraining (1313345) | more than 3 years ago | (#34471538)

Re:"Common" mistakes (2)

prionic6 (858109) | more than 3 years ago | (#34471656)

I really could not find much data, but the total number of surgical
procedures performed in the U.S. per year is around 70 million. I'd expect the UK to have at least 10% of that. That means about 700 lost objects for 7000000 procedures, 1 in 10000. Pretty good track record, although these are not the only mistakes to happen of course.

Re:"Common" mistakes (5, Funny)

tudorl (841940) | more than 3 years ago | (#34471728)

Now that's what I call encapsulation :)

Re:"Common" mistakes (1)

cowboy76Spain (815442) | more than 3 years ago | (#34471744)

I would have that patient(*) arrested for trying to steal a complete surgery unit...

As per TFA (as I only read them once every while, when I read it I quote it), it just states 6 issues (security, user freedom) and says "don't do it too much, don't do it too little"). Useless, because the point is knowing exactly what is too much or too little.

*: I know it says "patients"... but the joke is worth it..

Re:"Common" mistakes (1)

Alex Belits (437) | more than 3 years ago | (#34471788)

It's not about "too much" or "too little", it's about decisions that make absolutely no sense.

Re:"Common" mistakes (1)

Trivial Solutions (1724416) | more than 3 years ago | (#34471688)

God and I laugh at you, silly fool.

God comes from empirical sources, not philosophy.
Try the occult.

God says...
hatchet Nebridius strength release see purpose zip knew
dormant Identification broad easily doubt evermore theatres
pronounced milky BUT land six applauded For bulky hidden
whoso startled cares riotous ancient meets divine table
bidden falls arguments condemnation deceitful Unity Gentiles
Catechumen copies prejudice redoubling Oratory partake
unlike presence relaxing draw strike entireness captain
hardship ashes wild Carolina remnants deeper vainglorious
twenty furtherance sharp consumed entrusted Themselves
shuns inheritance beatific enlarging lives Be subordinate
comparison hook choler Bear request diligently departed
His precipice deserved carest

Re:"Common" mistakes (2)

erroneus (253617) | more than 3 years ago | (#34471874)

While I agree with what you say, the problem is that bad programming is largely the result of cultural personality shift.

Lately, I have been taking some classes on web development... yeah I don't know Photoshop, Illustrator or Flash particularly well -- I like text editors though dreamweaver is growing on me. There is one person in the class who is all about shortcuts. He doesn't want to understand anything, he just wants "results." He's a business man who runs a company that is all about outsourcing. He actually doesn't know anything and doesn't do much of anything -- he's a project manager. He gets wind of a project, starts advertising job positions based on the project and then bids on the project. Business outsource to people like him, who in turn, outsources to others. All the while, he knows next to nothing about what is going on or how to do it. Why is this bad? Simple: QUALITY. How does he know if it's good quality? How does he know if it's secure or stable? He can't, he doesn't and he doesn't care. He is the personification of what is wrong with our current business practices. LOTS of people are like this and getting increasingly like this. This includes programmers and especially younger programmers.

I have a co-worker who fancies himself a programmer. Looking at his results, I would have agreed with him. But one day, I was tired of the way his table output looked, so I went in to patch it to put "" in where all empty cells would appear. It was super easy. But looking at his code was not! I was shocked and disturbed by what I saw in his source code. A professional he is not. Not comment one in his code. Structure was for crap. It reminded me of my days programming BASIC on Apple/Commodore/TRS-80. You "think it and write it" was my style back then and is apparently his style now. The world needs a LOT less of this. Meanwhile, REAL programmers get no recognition and want none... they care about the quality of the code while project manager care about deadlines.

Once upon a time, programming was an art of out-thinking the user. It was often a game of predicting their mistakes and stupidity and working to prevent them from blowing the system up. The article opens up with precisely this mind set. But before long, programming short cuts began appearing and even "write a program without writing any code" started to appear. (When I first saw "RAD" tools, I cringed heavily. "Are people really comfortable not knowing what these black boxes do?" Apparently, YES!)

I once commented on a topic about programming and validating input. I was responded to with a lot of negative feedback talking about how much time and trouble it is; how much of a performance issue it could cause. I was shocked that people actually felt that way. (Heh, someone even tried to school me on "RegEx" processing... did I really have to point out that more simple and direct methods are actually faster? Sure, RegEx-s occupy a smaller portion of your source code, but the object code and library dependencies are often higher, not to mention that "generic" code blobs often do a lot of unnecessary things. It's cool, I get it -- I think in terms of assembly language and I care about wasted instructions and wasted memory -- I grew up in a 64k limited environment.)

Should programmers be fired for making "common mistakes"? Well, yes and no. I say no because I wouldn't consider anyone who makes those mistakes to be "programmers."

Re:"Common" mistakes (1)

deoxyribonucleose (993319) | more than 3 years ago | (#34471972)

The only common mistake I see is not firing the programmer who makes any of those "common" mistakes. There is absolutely no reason for any of this shit to be "common" unless "programmers" who make them are uneducated dumbasses who should never be allowed anywhere near software development.

Hardly these mistakes, surely? Most of these 'mistakes' are judgment calls, and any programmer will be guilty of most of them if put under sufficient time pressure.

Also, as a wise man observed, housebreaking a pet by killing the puppy the first time it pees on the rug is a bit inefficient.

Re:"Common" mistakes (0)

Alex Belits (437) | more than 3 years ago | (#34472042)

Most of these 'mistakes' are judgment calls,

Everything a programmer does is a judgment call.

and any programmer will be guilty of most of them if put under sufficient time pressure.

"Any programmer" can mess up implementation if he is in a hurry. Bad design is a sign of stupidity and ignorance.

Also, as a wise man observed, housebreaking a pet by killing the puppy the first time it pees on the rug is a bit inefficient.

There are huge organizations called "schools" made specifically for the purpose of educating people. Once someone works as a programmer, it's too late to tolerate idiotic crap from him.

Pointer typedefs (4, Insightful)

QuoteMstr (55051) | more than 3 years ago | (#34471564)

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.

Re:Pointer typedefs (1)

Alex Belits (437) | more than 3 years ago | (#34471590)

People DO THAT???

Re:Pointer typedefs (1)

QuoteMstr (55051) | more than 3 years ago | (#34471624)

Ever see Windows code?

Re:Pointer typedefs (0)

Anonymous Coward | more than 3 years ago | (#34471654)

unfortunately I see it every day

Re:Pointer typedefs (1)

$RANDOMLUSER (804576) | more than 3 years ago | (#34471686)

That const doesn't do what you think it does.

It never does.

Re:Pointer typedefs (1)

ColdGrits (204506) | more than 3 years ago | (#34471870)

That const doesn't do what you think it does.

It never does.

Fundamental rules of programming -

  1. Constants aren't.
  2. Variables won't.

Re:Pointer typedefs (1)

luis_a_espinal (1810296) | more than 3 years ago | (#34471716)

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.

Re:Pointer typedefs (3, Informative)

Psychotria (953670) | more than 3 years ago | (#34471732)

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 (4, Informative)

$RANDOMLUSER (804576) | more than 3 years ago | (#34471762)

His point was that a PFOO is a POINTER to a struct _FOO, and so when you say void SomeFunction(const PFOO), you're saying that the POINTER is constant, not the thing being pointed to, which is probably not what was intended. Since the definition of PFOO is located elsewhere, probably in another header file, it's easy to get yourself confused as to what data type you're dealing with.

Re:Pointer typedefs (1)

mosschops (413617) | more than 3 years ago | (#34471848)

I've never come across that mix of separate attributes with defined types. Typically there will be a PCFOO to go with the PFOO, which has the const as part of the typedef: such as LPSTR and LPCSTR.

Typedefs allow you to keep the whole type atomic. I prefer:

PCSTR p1, p2;

to

const char *p1, *p2;

where the pointer symbol needs to be repeated on the second variable, despite 'const char' being common to both.

Re:Pointer typedefs (2)

The New Andy (873493) | more than 3 years ago | (#34471958)

The obvious reason you might want a typedef like that is for a mostly-opaque data-structure, where you have several different implementations, some of which require a level of indirection, some of which don't. (The "mostly" in "mostly-opaque" is there to mean that calling code never accesses the type directly, but the type is complete, so the compiler can put it on the stack).

In short - pointer typedefs are good for the times when you really want to say "this is data of some type, maybe a pointer, maybe a struct, maybe an int".

(oh, and to add to your complaints about that code - _FOO is also a reserved identifier...)

Re:Pointer typedefs (1)

Arlet (29997) | more than 3 years ago | (#34471998)

My pet peeve is the unnecessary use of the underscore in struct _FOO. I prefer this:

typedef struct foo { int blah; } foo;

I hate caps too, except for constants.

Best way to handle nulls? (1)

Compaqt (1758360) | more than 3 years ago | (#34471576)

He gives one example of an attempt to avoid null pointer errors in Java next:

  public String getFirstName(Person person) {
            return person?.getName()?.getGivenName();
        }

But is it a good idea to use null to mean "no value specified"? What would be better, and what are the tradeoffs? Storing 0 or ""? Storing a special (constant/static) instance object nullValue?

Re:Best way to handle nulls? (1)

Chrisq (894406) | more than 3 years ago | (#34471678)

He gives one example of an attempt to avoid null pointer errors in Java next:

public String getFirstName(Person person) { return person?.getName()?.getGivenName(); }

But is it a good idea to use null to mean "no value specified"? What would be better, and what are the tradeoffs? Storing 0 or ""? Storing a special (constant/static) instance object nullValue?

I think it is useful to collect the NULLs together to deal with at a higher level - a quick way to deal with a null person, name, or given name identically.
Scala has a type "None [sanaulla.info] " that does mean no value specified. I haven't got my head over the trade-offs, pros and cons but it seems to work nicely in case statements.

Re:Best way to handle nulls? (1)

Alex Belits (437) | more than 3 years ago | (#34471722)

Anything as long as it's consistent.

And "fixing invalid values" is a completely retarded idea to begin with.

Programming Mistakes To Avoid (5, Funny)

$RANDOMLUSER (804576) | more than 3 years ago | (#34471628)

1) VB
2) Perl
3) Silver bullets
3) Writing your own "framework".
4) Using somebody else's "framework".

Re:Programming Mistakes To Avoid (1)

rrohbeck (944847) | more than 3 years ago | (#34471824)

Whenever yo hear "framework", run like hell.

Re:Programming Mistakes To Avoid (1)

cowboy76Spain (815442) | more than 3 years ago | (#34471964)

I don't see many problems using a well-defined, well-supported framework you are familiar with.

Of course, the part of being familiar with it means an overhead that can be important. If you are just going to use it once, maybe it is not worth the time using it (if it is optional). But once you get to know it, many of them are good at solving the issues they were created for...

If we follow the trend of "frameworks does not serve at anything", we'll be back to programming in assembly soon.

GOTO... (3, Funny)

Ecuador (740021) | more than 3 years ago | (#34471634)

Is it indecent of me to reminisce on the days of olde when such a topic would simply turn into a lengthy discussion mocking BASIC programmers?

Re:GOTO... (1)

Errol backfiring (1280012) | more than 3 years ago | (#34471810)

Not really. VB grew up (it is now just java with syntactic sugar). PHP, on the other hand, is going back to the 80s of the previous century.

Re:GOTO... (1)

rrohbeck (944847) | more than 3 years ago | (#34471830)

You won't believe how many GOTOs I see regularly in our C/C++ sources :(

Re:GOTO... (1)

Anonymous Coward | more than 3 years ago | (#34471968)

You won't believe how many GOTOs I see regularly in our C/C++ sources :(

Come now, we don't know if this is good or bad until we see the "GOTO" macro!

On a more serious note, goto's for local jumps can often lead to cleaner code. [kerneltrap.org] I use goto whenever I see fit and I'm not polite when someone blindly parroting a 40 year old essay challenges me on it.

to avoid what? (1)

zwarte piet (1023413) | more than 3 years ago | (#34471668)

I'm supposed to program mistakes to avoid what?

Re:to avoid what? (1)

rrohbeck (944847) | more than 3 years ago | (#34471834)

To avoid working code of course.

Is this real? (4, Insightful)

Psychotria (953670) | more than 3 years ago | (#34471684)

I've not worked as a programmer for, hmm, maybe 15 years and all of this was known way back even before I "retired" from that line of work. Perhaps all these levels of abstraction upon abstraction make things harder to understand. Back in my days these "pitfalls" were obvious because we all (well, not all, but a lot) knew ASM and actually even used it regularly (even inline, *shudder*).

Someone above mentioned pointer typedefs and gave the example of typedef struct { int Blah; } FOO, *PFOO; (yes I left off the bit before the the opening brace deliberately.) and then suggesting that people don't know that void SomeFunction (const PFOO) {} doesn't behave as expected. Now this could, I suppose, be seen as a failure of the language. But, shit, any idiot who understands the underlying logic can see why that causes problems. Which goes back to my point of maybe all these modern levels of abstraction and getting away from the machine are, in some ways, detrimental.

Now, get off my lawn. Umm, except I don't have a lawn because I sprayed the growth inducing hormone RoundUp all over it, but that is beside the point. I think.

Re:Is this real? (1)

turbidostato (878842) | more than 3 years ago | (#34472038)

"I've not worked as a programmer for, hmm, maybe 15 years and all of this was known way back even before I "retired" from that line of work."

Yes: there's an obvious problem with programming and it's that "we" as a guild are not building upon past experience. For the most part, the current generation of programmers are making the same kind of mistakes that where common -and learnt how to avoid, even 20 years ago. Can you imagine, say, aviation if you had to engineer an Airbus 380 all the way from Otto Lilienthal to-date instead of building on past knowledge? That's what I feel too many times when dealing with new development projects.

Now the question is: what could we do so new programmers start where the previous generation left instead of having to build their own knowledge almost all the way along again?

How to avoid mistakes (1)

wzzzzrd (886091) | more than 3 years ago | (#34471690)

Always think of your code as some sort of API if you care about clean, maintainable code. This is a good talk about API and code design: http://www.youtube.com/watch?v=aAb7hSCtvGw/ [youtube.com] from Josh Bloch. It's entertaining too.

strcpy and strncpy (0)

Anonymous Coward | more than 3 years ago | (#34471708)

I still find myself using strcpy. Good thing I don't have a job.

Re:strcpy and strncpy (1)

Alex Belits (437) | more than 3 years ago | (#34471756)

I often deliberately choose a string manipulation that involves strcpy() and even strcat(), just to make a point that those are perfectly valid and useful functions, despite some morons writing insecure code with them.

The only really unsafe function is gets().

Re:strcpy and strncpy (1)

dhavleak (912889) | more than 3 years ago | (#34471878)

I often deliberately choose a string manipulation that involves strcpy() and even strcat(), just to make a point that those are perfectly valid and useful functions, despite some morons writing insecure code with them.

The only really unsafe function is gets().

That's just stubbornness for it's own sake. These are violently unsafe functions. People do manage to make asses of themselves even with so-called 'safe' string APIs, but there's no good reason to not use them. Strcpy() or strcat() have pitfalls that are really esoteric, and if you keep using them you'll eventually make a mistake and end up with some absolute motherfucker of a bug with security ramifications you wouldn't even have imagined.

Re:strcpy and strncpy (0)

Anonymous Coward | more than 3 years ago | (#34472058)

The problem is that people made an absolutly crappy mess out of those so-called "safe" functions, strncpy is a pain since you still have to do the 0-termination, strlcpy is not generally available and can cause performance issues (and is a huge pain to re-implement correctly if you want it on systems that do not have it) and the Microsoft-only stuff seems not really worth discussing for that fact.
So congratulations to all involved: You helped a lot in making sure C keeps it reputation as unsafe and/or difficult to use.

Slashdot's programmers (0)

Anonymous Coward | more than 3 years ago | (#34471808)

I hate it when I click on "Many More" to read more Slashdot stories, then click on a link in one of them, then return to Slashdot to see it all collapsed again.
Same when one expands the Full/Abbreviated/Hidden slider.

When's that gonna be fixed ?

Philosophy for Software Designers (1)

Aceticon (140883) | more than 3 years ago | (#34471814)

I did went throught the list in TFA and while their "programming mistakes" list is sound, it's all over the place and often doesn't dig down to why should you do or not a certain thing.

So I decided to put down a list of, low level principles and concerns to consider when doing software. Given my own level of experience and the fact that I'm getting tired of maintining code by people who have never managed to cross the threshold from junior/medior software designer to senior designer, that is the target audience.

So here goes:
- When designing/coding software, assume that sooner or later it's going to be called-by/changed/extended by a junior developer. They cannot be relied on to recognize design structures or practices and will do things like passing bad parameters in, or incorrectly use it (for example, misusing a singleton). My solution to this is defensive design/coding: check for nulls at library entry points and fail-fast (avoid "junk-in junk-out" scenarios - those just make for data corruption and hard to track bugs), make sure things like singleton classes cannot be instanciated normaly, avoid obscure constructs that must be used in a "right way" (i.e. functions that should be called in a certain order) and overall try and make your design so that the natural way of using it is also the correct way.

- When designing software, before employing a certain construct (for example a design pattern) ask yourself "What do I want to achieve with it?". Complex software structures are used instead of simple (and easier to understand) ones because they achieve certain objectives which outweight the increase in complexity - don't use it because it's fancy/fashionable/elegant/everybody-does-it: those are not proper reasons. The cost to maintain, support and extend code grows with code size and complexity and using fancy structures just because is a way to dig a deep hole for your colleagues and your future self. Consider that it's allways cheaper to "add it later if and when we need it" than "maintain code that is twice the size for 6 months". For example, what is achieved by defining an interface for which now (and in the foreseeable future) only one implementation exists?

- Design and code your software so that Responsabilities and Domain-knowledge are contained together in their own modules/classes. Avoid leakage of concerns (i.e. "we do it this way here because we know that the code we call in another module works in such and such way"). This makes it easier to find ALL the code responsible for doing a certain kind of thing and avoids the dreaded "I changed it in one place but forgot to change it in another place" problem. For example, don't mix your database access code (that knows all about SQL and tables and such) with your web-page generation code (which is experting in user interaction via HTML) since they are independent domains (you can have one without the other).

Programming Mistakes to avoid (1)

maroberts (15852) | more than 3 years ago | (#34471832)

Being still employed by the company when the project goes overtime and over budget.
Experienced programmers should've found another employer at a higher salary before their incompetence is discovered....

Mistake Number 1 (1)

Fnord666 (889225) | more than 3 years ago | (#34471860)

Make sure the code in your article compiles or is even legal syntax. The following is supposedly sample Java code:

public String getFirstName(Person person) {
return person?.getName()?.getGivenName();
}

WTF?

Re:Mistake Number 1 (0)

Anonymous Coward | more than 3 years ago | (#34471900)

Did you even read the paragraph above that?

The worst part about sloppy programming is that advances in language design aimed to fix these problems don't do their job. Take the latest version of Java, which tries to make null-pointer checking easier by offering shorthand syntax for the endless pointer testing. Just adding a question mark to each method invocation automatically includes a test for null pointers, replacing a rat's nest of if-then statements, such as:

Mistake Number 1: You expected people to read documentation.

Re:Mistake Number 1 (1)

Terrasque (796014) | more than 3 years ago | (#34472006)

My two questions when reading that:

1. If there is a null pointer in there, what would the return be?

2. Would the return be any more useful than the default mode (which would be crash + burn)?

Meh it's not all programming (1)

js3 (319268) | more than 3 years ago | (#34471872)

Half of these are design mistakes

my favorite: more is always better (1)

Uzik2 (679490) | more than 3 years ago | (#34471906)

Just add more code! That always makes it better. Closely followed by "It's unreliable/broken" "We've got to rewrite that old xxxx in m$'s new blah-ty-blah framework!".

Nice try Boss (0)

Anonymous Coward | more than 3 years ago | (#34471912)

I was never anywhere the server last night!

Two Major Mistakes (5, Funny)

grcumb (781340) | more than 3 years ago | (#34471926)

My two most common mistakes:

  1. Variable scoping
  2. Memory leaks
  3. Off-by-one errors

The PRE programming mistakes (4, Insightful)

petes_PoV (912422) | more than 3 years ago | (#34471944)

By the time the coding starts, most projects are already doomed. The basic mistakes that occur before any code is written have a far greater effect on the project. While these are almost all outside the control of the programmer, he/she always gets the blame due to the "last person who touched it, broke it" principle. My short list of favourites would be:

Allowing too many options / features in the design. The classic example being unable to decide whether feature A or B is best, and ducking the issue by including them both

Assuming 5 working-days of effort can be achieved in a working week. Conveniently forgetting about all the office overheads such as "progress" meetings, timesheet administration, interrupted work, all the other concurrent projects. Even the most efficient, single-threaded operation needs half a working-day per week just for the trivia.

Following on from that, conveniently forgetting about annual leave commitments, national holidays and the possibility of sickness. If 5 working-days per week is impractical, 12 working-months in a year is downright negligent.

The tacit assumption that testing will inevitably be followed by reelase - rather than bug-fixing.

Holding the end-date constant while delaying the start, or presuming that all delays in the specification, design, approval stages can somehow be reclaimed during coding (how: by thining faster?)

Re:The PRE programming mistakes (1)

WillerZ (814133) | more than 3 years ago | (#34472020)

Just out of interest, do you work at IBM?

Avoid over engineering and over generalising (3, Insightful)

rgravina (520410) | more than 3 years ago | (#34471978)

The biggest programming mistakes I've had the displeasure of making, or discovering in others code, almost always centre around one of these two problems:

1. The code is over-engineered
2. The code was abstracted before there was even a need for the abstraction.

I remember when I was less experienced, how thrilled I'd be over code that was clever, solved many problems aside from the one I was trying to solve, and had some clear reusability built in. What a work of art, I thought.... until I eventually realised that much of the extra code I had written didn't get used, the abstracted code was never reused - or even if it was, I couldn't predict how it would be reused and the abstraction was clumsy at best, useless at worst.

It's sad when this happens - good intentions, but the end result is a lot of waste. I'm embarrassed to look over my earlier code which is like this.. I like to think I do it less now, but the temptation is always there... I'm going to need to do this later anyway... I can just abstract this bit here and reuse it some day in the future...

My advice now... Don't do it! Just wait until the reuse case comes along, or the new feature request comes along, and *then* do it. You'll know so much more about the problem domain then, or you might avoid days (weeks!) of wasted effort.

What common mistakes? (0)

Anonymous Coward | more than 3 years ago | (#34472022)

Java
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...