Slashdot Mirror


Ask Slashdot: What Makes Some Code Particularly Good?

itwbennett writes: When developers talk about what makes some source code particularly 'good,' a handful of qualities tend to get mentioned frequently (functional, readable, testable). What would you add to this list?

10 of 298 comments (clear)

  1. Obviously by Anonymous Coward · · Score: 5, Funny

    When it's mine.

    1. Re:Obviously by Anonymous+Brave+Guy · · Score: 4, Funny

      Tell that to your six-months-ago self, who wrote the mess you've been debugging all week. :-)

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    2. Re:Obviously by nitehawk214 · · Score: 4, Funny

      I hate it when I have to debug some other asshole's code.

      I hate it more when the asshole is six-months-ago-me.

      --
      I'm a good cook. I'm a fantastic eater. - Steven Brust
    3. Re:Obviously by stjobe · · Score: 4, Insightful

      I am all over the place, I guess many programmers are.

      Being a programmer is a trade in some parts, and you can get by with good craftsmanship.
      In other parts it's a creative art, and you can't force creativity.

      To write really good code, you need to both have the craftsmanship and the creativity.

      --
      "Total destruction the only solution" - Bob Marley
  2. When you go back to it several months later by Z80a · · Score: 5, Insightful

    And say "thank you, my past self for making this so easy to understand and versatile!".

  3. take it from a pro by nimbius · · Score: 4, Funny

    I think i can shed light on this subject, having several years experience in this field. New programmers and seasoned alike often make this mistake, either through carelessness or ignorance. When working to write good code, you must make sure to set good="yes" or good="veryyes." ive written code for 20 years now and this has only ever failed me in PHP. Apparently the language does not support "good" code.

    --
    Good people go to bed earlier.
  4. Re:Good code by orasio · · Score: 4, Interesting

    For newly written code, things like readability, testability, and maintainability all can come in to whether it is "good" or not

    For legacy stuff, Good code is code that works. Who cares how easy it is to read or test as long as it works?

    The second one should also include "immutable". If it's hard to understand it will evolve easily to non working, and time spent on improvements can start to creep up very fast.

    I have worked in very clever, solid code, but not easy to read. It was then maintained and extended by average, but competent programmers down the road, and turned into a big mess, only because it was so hard to understand.

    In my experience, good code is easy to read, above all. That will make it easy to extend it coherently, find bugs and stuff. Also, if it doesn't work OK, it's easy to find out why. The single metric that saves time, money, and improves quality down the road is readability. Eveything else should be suject to that.

    And, about the last point in the "article", "efficient", it's nonsense. Premature optimization is the root of all evil. You should _always_ follow the second rule of optimization (see http://c2.com/cgi/wiki?RulesOfOptimization ).

  5. Re:Compactness and Readability by Yunzil · · Score: 5, Insightful

    It communicates clearly what it is trying to do.

    It doesn't, actually. Looking at that as someone who doesn't know what a CRC32 is I have no idea why it's doing what it's doing. Some actual useful comments might be nice.

  6. It's good if they don't code like 90s C++ devs by gestalt_n_pepper · · Score: 4, Interesting

    Their whole mindset still makes me want to puke.

    Obfuscated crap. Techno-machismo teens playing games trying to get their code into the least number of characters and the least amount of memory. I've had to fix or test so much of this junk and it's still just plain stupid.

    The *human* part of the system is what *matters* and that includes the code interface. First, I want comments not about *what* is happening. I can read that. I need to know *why* it was done, so I don't undo it, or I can do something different safely. Comments should be one liners, limited to "why" and sometimes "how".

    If adding a variable aids readability, add the fucking variable! Shove all the results into a meaningful, readable variable name and then shove *that* into your function argument, not some long series of nested function. It's not the 90s. You don't have to save memory! Memory is there to make your code readable. Use it!

    Ok, rant over. I'm going back to work now.

    --
    Please do not read this sig. Thank you.
  7. Re:Well commented. by Jamu · · Score: 5, Funny

    What if the comment is // this code sucks.?

    --
    Who ordered that?