digg

Join DiggAbout

The Digg Crew wants to hear your thoughts!
Please take our short survey about Digg and potential feature ideas.

Top Ten List of Programming Advice to NOT Follow

chrylers.com — Addresses some of the most common things people are being told about programming with which the author disagrees.

show profanity settings
expand all
  • Skrolnik, on 10/12/2007, -3/+1meh.
  • moron, on 10/12/2007, -1/+7Some of the worst suggestions by the author ever. Seriously, it sounds like someone who has never worked on a large project or had to create something that was going to be maintained for years. Some things he mentions are OK, but many are just outright flawed.
  • CaughtThinking, on 10/12/2007, -0/+3"though it seems most of the deep hierarchy people have moved to Java and C#, leaving the C++ community to evolve in a direction that I think is more promising."

    Actually concrete inheritance is frowned upon by any programmer that knows squat about OO programming. As for the Singleton, there's a whole religion dedicated to scoffing at that pattern know, but again, it's by people who didn't know squat about structure and over-singletonned everything. Maybe they should revisit the concept of a static vs. global vs. necessarily unique.

    Maybe one day he'll enlighten us with a blog about how Ruby on Rails solves the Java problem too.
  • egbert, on 10/12/2007, -1/+2I stopped reading at number 9 (the second one). The author obviously does not understand why size_t has to be unsigned.
  • DonWilson, on 10/12/2007, -2/+0I feel like I'm back in preschool when I read this.

    Any good programmer already knows all of these things.
  • TokenUser, on 10/12/2007, -2/+3No digg for really crappy advice.
  • Jack9, on 10/12/2007, -2/+1No digg for contributing to stupidity.
  • oluckboy, on 10/12/2007, -0/+4As pirate Barbossa said....

    "... the Code is more what you'd call "guidelines" than actual rules. Welcome aboard the Black Pearl, Miss Turner!"

    Listen to the pirate and skip the article.
  • inkswamp, on 10/12/2007, -0/+0> Write lots of comments

    So he's saying to make the code more obvious instead of adding more comments?

    Fine. That's great if you have lots of time to craft the perfect code, but the reality is that most tasks need to be programmed quickly and cranked out fast. I suspect most programmers are not given the time to structure their code in beautiful and clear ways. Commenting in that situation can be a bit of a band-aid, but it's better than nothing.

    Besides, commenting doesn't hurt anything, doesn't affect the functioning of the code, doesn't take a lot of time to do as you go.
  • partialinfinity, on 10/12/2007, -1/+0Egbert, can you explain it to the rest of the class?
  • sshack, on 10/12/2007, -1/+1What a horrible article. This guy knows absolutely nothing about the real world.
    and jesus, he doesn't know why size_t is unsigned, yet he thinks he has the authority to tell people not to use it?

    Guy, go get yourself a degree and spend another 10 years in the industry (not doing ***** webmonkey crap) then you might be able to come up with a list of 2 things not to do.
  • longman2g, on 10/12/2007, -0/+1the number 1 thing he says which is bad, design before coding, is a very easy thing to do, and save you a lot of time. Yes, you might spend a few days laying out the entire design of the program, and you probably will make some mistakes, but it is much easier to catch exactly what those mistakes are when you can see the program as whole right in front of you. If you get the hardest part out of the way in the beginning, then all you have to do is go through and write the code, instead of designing and redesigning it multiple times.
  • arnett, on 10/12/2007, -0/+1All of these ideas are counterintuitive. Most are counterintuitive because they are simply incorrect.
  • renegadetempest, on 10/12/2007, -0/+0Wow. There are some completely flawed ideas in this piece. While I believe there are very few tried and true maxims in building systems (and in life for that matter), I think there are much better ways of building. Again, there are reasons people reiterate these guidelines.

    No Digg.
  • Archimboldo, on 10/12/2007, -0/+1Crappy advice. No digg.
  • AarronT123, on 10/12/2007, -0/+1Terrible article!
  • kish, on 10/12/2007, -0/+2Wow, no digg, this is terrible.

    I haven't read past #9. The point about "use exceptions" followed by the point about "don't use unsigned because STL does and wraps values rather than indicating an error" makes ZERO sense. If that's how STL does it, then either STL should throw an error on an overflow or the user should check the bounds. That's why implementers make the behavior clear in the exception cases, so you know how they expect you to handle them.

    As egbert says, the author obviously doesn't understand why unsigned is used.
  • C_MAC, on 10/12/2007, -0/+0It's interesting to see another person's approach to pogramming, but I disagree with some points, particularly number one! You cannot approach a large scale project by coding first and asking questions later. Maybe if it's a personal project, but you'll get laughed at when you finally get a job.
  • prthealien, on 10/12/2007, -0/+0Informative article, but it seems most of you disagree. The only thing I agreed on was using exceptions.
  • MyKungFu, on 10/12/2007, -0/+0If you truly want to know how NOT to program, then Joel is the way to go (read his "Never use exceptions" for a good laugh.)

    He doesn't eat his own dog food either. His software is a joke. I've used FogBugz, which is completely broken on Firefox, and when something fails it often spits out raw SQL statements into your browser.

    When "Joel on Software" works in "Joel on Firefox", maybe then his advice will be worth a damn.

  • Lewisham, on 10/12/2007, -0/+0This is horrific. If he did *all* of these things, his programs would be better, and his experience coding them nicer. They feel complete.

    I shudder to think what his co-workers have to put up with.
  • Philoushka, on 10/12/2007, -0/+1I am not sure if I am not digging this because the article is so smart-ass, whether the author is so full of himself, or whether this author is so tongue-in-cheek that my sarcasm meter is broken.

    Either way, no digg.

    I do agree on the part about putting the author name, date, changed etc in the comments above a method. True, it does belong in the source code control mechanism WHEN THERE ACTUALLY IS ONE. :) For websites, sometimes this just does not happen.
  • rolosworld, on 10/12/2007, -0/+0I think this guy gives consultant talks to the programmers at MS.. LOL
    I can see why 10 could be true in some cases.. but 9 is scary, so I didn't want to waste more time...
    Top Two List of Programming Advice to Not Follow:
    1-RTFA
    2-digg this
  • Cossins, on 10/12/2007, -0/+0Seemed pretty reasonable to me...

    Since it's so obvious to everyone why size_type is unsigned, can somebody explain it to those of us who don't claim to be coding gurus?

    Digg digg digg.

    - Simon
  • maram500, on 10/12/2007, -2/+0I like every tip EXCEPT the first one, and this hearkens back to my days in CMPS 120--Introductory Programming. Thanks doc. Anyway, he always instructed us to design whatever we were programming first, and THEN AND ONLY THEN to code it. And that is how I code stuff to this day. Other than that, the list seems to be pretty clean-cut.
  • LewsTherin, on 10/12/2007, -0/+0The headline is correct. None of the advice in the article should be followed.
  • architectzero, on 10/12/2007, -0/+0advice from a developer still in training pants

    no digg
  • cstmoore, on 10/12/2007, -0/+0Craptacular. No digg
  • Dangerman, on 10/12/2007, -0/+2Wow, I read most of his points and thought "Why is everyone disagreeing with him, most of these are decent?", it was at that point I realized that he was saying NOT to do these things.
    This kid is an amateur, my ten year old writes better code.
  • SnakeO, on 10/12/2007, -0/+0article.sucks = true;
  • aubray1741, on 10/12/2007, -1/+1229 diggs? I really hate the buttons to dig a story before you even read it on the front page. This is mostly bad advice for programmers. Especially the part about comments, to me. And integers, OO, and many other things are relative to the programming language and project you're working on.
  • adidax, on 10/12/2007, -0/+0#1 (the last one is applicable to everything EXCEPT coding with more than 1 person. If you sit down and think about it, draw out UMD's and such, by yourself, for more than a day, you are probably wasting time, because you probably won't catch most of your own mistakes (i.e. why book authors give their books to 3rd parties to proofread). *HOWEVER* the purpose of planning is to catch mistakes early, and if you plan, and let other people look at it, mistakes WILL be caught, and then you won't find yourself rewriting code that you overlooked some crappy, little detail.

    and #2, if you don't finish a function or a module or a class, and you're the only one working on the project, maybe it doesn't matter, but once you say it's done, and it works, and co-workers try to use it, and it's only half-Assad implemented, be prepared for torches and pitch-forks, because a lynch mob is coming to your house tonight.

    bad article, very very bad.
  • pcgeek101, on 10/12/2007, -0/+0Person SnakeO = new Person("SnakeO");
    SnakeO.IsCorrect = true;
    Application.Exit();
  • vokiel, on 10/12/2007, -0/+02-3 of these advices are obvious, the rest is uneducated.
  • pcgeek101, on 10/12/2007, -0/+0I guess what bugs me most about this article is the author's elitist attitude ... especially when he's simply stating his own opinion on the matters at hand; he isn't even providing any relevant text to the article ... it's just a huge crybaby rant about why the world should follow HIS standards. *sigh*
  • Vampyric, on 10/12/2007, -0/+6I don't necessarily agree with every point the author makes, but the supposed know-it-alls on here calling this horrific are laughable. You either did not read his reasoning or did not follow it.

    For instance, in 1) his point is that it is not necessary to have a complete design to begin coding. This is actually an axiom of extreme programming. If you have complete tests and refactor, you design interatively instead of up front. You have condfidence in refeactoring precisely because you have complete tests.

    Also, the point about unsigned int vs signed int seemed to go over your heads...the point is that in C/C++ you are not actually preventing bugs but trading one form of bug for another because there is no runtime detection of overflow. If you have unsigned int foo, if someone does foo = -1, it didn't help you any. There is no detection of it. You just wind up with foo = 0xffffffff which is just as wrong. I don't necessarily agree overall, but that people would react so derisvely too it shows that you simply don't understand.

    Just generally i see a lot of snide remarks but no counterarguments. The irony of digg comments is that whenever a non-technical article is posted people complain that digg is for technical stuff, but when something technical is actually posted, the level of discourse is terrible. Slashdot may not be the be all and end all of technical user discussion, but holy cow, it makes digg look like dogcrap in comparison. A better moderation system is sorely needed.



  • reubix, on 10/12/2007, -1/+1groupthink fools.
  • a1programmer, on 10/12/2007, -0/+0Not good... Some of these, you actually want to follow...
  • ezweave, on 10/12/2007, -0/+2Some of these things are true:

    Exceptions are a must if you are coding something for someone else to use later (and you know this: i.e. open source projects, etc)... it can be hard to find runtime NPEs (or NREs depending on language).

    Don't comment obvious things. (i = 0; //Now, I initialize 'i' to 0)

    Singletons are useful.

    Others are a bit dubious: design is important, corner cases might be needed... TODO lists don't always work, coding standards are vital for big projects... take some SE QA courses to learn why...

    It's ok, I don't know how this is authoritative. Besides, I am not going to tell some CS100 student to do half of these things. Not when they can't tell the difference between "long" and "Long"... haha.
  • ezweave, on 10/12/2007, -0/+0Oh and getters and setters (accessors) are vital if you need some lazy instantiation. Accessors should always be supplied, it does not hurt to make stuff readable.... if the design makes sense (there is a purpose for private/protected scope).
  • jeff1943, on 10/12/2007, -1/+0Horrible
  • cecil_t, on 10/12/2007, -1/+2I digg it. I agree with about half of what he says, and as he said these are things that have to be learned for yourself from experience. It sounds like all you no-digg'ers are fresh out of school or work for a very large company who just drops in junior level programmers to write code that has already been designed by a software architect. His advice seems to be oriented to experienced programmers who work in smaller development teams.
  • Inkling, on 10/12/2007, -1/+0Horrible advice, this author has never worked with a team before. He may have been around a group of programmers, but he's never been in an environment that worked coherently as a team.
  • 1diot_savant, on 10/12/2007, -3/+0This is lame
  • almightystoph, on 10/12/2007, -1/+0This guy is an idiot. Anyone who has worked on a big project knows you are dead from the start if you don't plan.

    Although here's some code I didn't plan first...
    --digg;
  • exick, on 10/12/2007, -0/+0"Why on earth you would clutter the code with information that so obviously belongs in the version control system is just beyond me."

    Because, in the real world, the people who have access to the version control system's information are CM and the coders when they're coding. Having a header show up between two versions makes differences easy to see and is especially useful when tracking changes with bug/trouble reports.
  • egbert, on 10/12/2007, -0/+1There are many reasons for size_t. One of them being addressing more than 2G of memory on a 32-bit machine.
  • gcauthon, on 10/12/2007, -0/+4This is retarded.

    10: Use exceptions for handling exceptional situations. It's a way for the compiler to optimize the code by indicating "this branch is hardly ever taken".

    9: Declare unsigned parameters as a way of self-documenting that you only expect a positive number to be passed.

    8: This is just a way to teach OO to beginners. Nobody actually expects you to have classes like Cat and Dog that extend Animal.

    7: If you waste time reformatting someone's code then it is difficult to see if you actually made any worthwhile changes. Reformatting the way YOU like makes it a reall PITA for someone to track your changes.

    6: I've never heard this one. I've been programming for a long time and I've never heard anyone say "write LOTS of comments".

    5: I'm confused. Are you for or against public fields?

    4: . . . ok I'm bored of this.
  • rubicante, on 10/12/2007, -0/+2I totally agree with a couple of the things he says - as unpopular as they are. People just like to reiterate "good programming techniques" because it reinforces their ego without actually assessing whether or not that technique has actually saved them time and/or made their project more successful.
  • Otto, on 10/12/2007, -0/+1Yeesh. For those who don't know, size_t is unsigned for two very good reasons:
    a) A negative size doesn't make any sense whatsoever, and
    b) Memory addressing is unsigned as well, because memory starts at zero and goes up from there.

    You're a program. You have this virtual address space which is 4 gig long. You know the address of some variable in memory, and it happens to be at about the middle of that address space. You also know the size of that variable. If the size and the address are both unsigned, then you can add them and get the address following that variable with no hassles.
    But if the address is unsigned and the size is signed, then you can't add them at all. You'll have to convert one of them to the other in order to do that addition. And regardless of which one you convert, you could lose information. Signed->Unsigned doesn't cover negatives (even though it doesn't matter this particular case), and unsigned to signed could lose the top half of the space (and since you have 4 gig of virtual memory, this is easily a bad thing).

    Having size_t as an unsigned ensures that you're using the same mapping for your sizes as you are for your addressing. Or, at least, that you can convert one of them without loss of information (if size is 32bit and your use 64bit addressing, you can promote the size to 64bit and guarantee no loss of information).

    Although having a signed size will sometimes work, sometimes it won't. And when it doesn't, your program goes off into lalaland because you hosed some address pointer.

    The rest of the article is similarly stupid. No digg.
  • Fetching more discussions...
    Show 51 - 84 of 84 discussions
  •  

    Login or register to add a comment

    Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.


© Digg Inc. 2008 — Content posted by Digg users is dedicated to the public domain.
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.