Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Ask Slashdot: What Makes Some Code Particularly Good? 298

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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Makes Some Code Particularly Good?

Comments Filter:
  • Obviously (Score:5, Funny)

    by Anonymous Coward on Friday March 27, 2015 @02:19PM (#49356135)

    When it's mine.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      What makes an article a click whoring waste of time? I don't know, I didn't read past the first for 9 impression generating lazily written dreck, but being posted on slashdot is becoming a good indication.

      • There *IS* one problem here: efficiency is the last item, while "simple" and "pleasant to look at" are given higher priority on the list.

        Yes, that is a regrettable trend I've seen lately. Yes, code should be readable, and should be easy to maintain. But there is a huge amount -- maybe even majority -- of time when efficiency should be considered before readability or beauty.
      • I will elaborate just a little:

        I have personally seen code essential to execution time, which was neat and canonical, made literally more than 100 times more efficient in the sense of time and CPU cycles, by using methods that were a little less readable.

        And I mean via testing, not just subjective impression.

        TFA has its priorities skewed.
    • by Anonymous Brave Guy ( 457657 ) on Friday March 27, 2015 @02:50PM (#49356491)

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

    • not to be confused with code that sorta looks like it, but surely doesn't smell like it...

    • by plopez ( 54068 )

      When it's mine and I am the only one who understands it and so therefore have a cash cow until retirement :)

  • Because it's mine! (Score:4, Insightful)

    by DickBreath ( 207180 ) on Friday March 27, 2015 @02:21PM (#49356153) Homepage
    Doesn't every self important developer think that their own code is the best?

    How many managers does it take to reach a decision to begin a study to determine whether a light bulb should be replaced?
  • must fail (Score:4, Insightful)

    by BytePusher ( 209961 ) on Friday March 27, 2015 @02:22PM (#49356161) Homepage
    Code needs to fail in an easy to understand and predictable way. If possible and practical provide descriptive and easy to follow details through logging or return values...
    • by Rob Y. ( 110975 )

      Yep. I've had C++ coders who were not building general purpose libraries, but still insisted on throwing exceptions in cases of fatal errors (because 'that's what you do'?). The caller would then catch the exception and then call a routine to log the error and core dump for later debugging. But dumping at the site of the caller discards all the detailed information and variables that would've been available in the core dump if the damn app just logged and dumped at the site of the error instead of throwi

      • by swilver ( 617741 )

        It is good practice to throw exceptions for even fatal errors. What they've missed however is to add information to the exception about the error (the stuff you propose they should log).

        Somewhere way up the call stack you have a catch all exception handler, which is responsible for logging the exception -- so it is not necesarilly the caller who logs this. If the caller cannot handle the exception, it should just leave it and let it bubble up.

        This way there's no need to duplicate logging code in every sma

  • by Z80a ( 971949 ) on Friday March 27, 2015 @02:22PM (#49356169)

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

  • by Anonymous Coward

    Code that you can change, and the change does what you expected and did'nt ruin something else in a seemingly unrelated place.

    Doesn't matter if the code is otherwise butt ugly, as long as you can do this, the code is good enough to be workable.

    • by Xolotl ( 675282 )
      I was looking for a comment along these lines .. exactly. Over the years I've found that good code is that which can be opened up months or years after it was written and changed or repurposed easily. Good programmers seem to write this instinctively.
  • a few heuristics (Score:4, Insightful)

    by Sneftel ( 15416 ) on Friday March 27, 2015 @02:27PM (#49356229)

    Good code feels obvious and self-evident, as though its design springs directly from the problem, rather than from the cleverness of the developer.

    Good code is free of regret; regardless of how much it's been modified and refactored, it feels as though it was written in a single sitting, by a developer who somehow knew the right way to do it already.

    Good code is not just readable, but inviting. It feels as though there is no wrong place to start reading it.

    Good code doesn't have a single goddamn class named "Manager".

  • by QuietLagoon ( 813062 ) on Friday March 27, 2015 @02:27PM (#49356233)
    That it works.
    • Was reading through to see if I had to add that. Glad you did. It's really the most obvious and should have been first on the list.
    • by stjobe ( 78285 )

      To paraphrase Torvalds:

      If it compiles, it's good. If it runs, ship it.

  • When it works.

    No, seriously, that's the prime criteria. I'll take crap code over good code anytime, it it works and the "good" code needs some arcance and/or bizar setup procedure that I have to put up with to perhaps get it running.

    Point in case: WordPress, a PHP driven Web CMS that today runs about 20% of all websites, is a huge pile of typical PHP spagetti. And don't even get me started on the data model ... the WP crew probably doesn't even know what that is. Anyway, just the other day I spent two hours

    • by Jaime2 ( 824950 )

      Whether it works is orthogonal to quality. Good code can be fixed easily, so good code is always a short distance from "it works". Bad code can quickly go from "it works" to "it doesn't work and I don't know why" with just a simple change in requirements.

      One of my rules is that the customer is the judge of whether is works or not, but the team is the judge of whether it is good or not. If the only person to evaluate the product is the customer, then you are pretty much guaranteed to have bad code. Code qual

      • Whether it works is orthogonal to quality.

        I'd say that if it doesn't work, it's of pretty poor quality.

  • Personally, I like speed. It must be fast, you can comment out a nice readable version, but the one to be compiled must be fast.

    • by Jaime2 ( 824950 )
      You can usually make good fast without much effort. It's often hard to make fast code good. Prioritizing speed above all else is a recipe for disaster.
    • I think programmers should focus on making code that "isn't slow" more than they should focus on "is fast." Focus on not making stupid mistakes like running higher-order algorithms than necessary (ala using a for loop to search for a key when you could have been using a dictionary).

      If you focus on fast, you should definitely do a profile-first-optimize-last approach so you're actually optimizing code that the computer spends most of it's time running.

      If you're optimizing fringe functions, then it better
  • by nimbius ( 983462 ) on Friday March 27, 2015 @02:35PM (#49356329) Homepage

    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.

  • by gurps_npc ( 621217 ) on Friday March 27, 2015 @02:38PM (#49356367) Homepage
    Yes, that is the key measure of how good your code is.

    If you have no rhyming variable names, then your code sucks. 1 stars

    If you have one or two, it is barely acceptable. 2 stars

    Half rhyme, then 3 stars.

    If most, but not all, rhyme, 4 stars.

    If every single variable rhymes with at least one other variable, you have a great job, 5 stars.

    To get the coveted 6 stars, all the variable names have to rhyme with each other.

  • Define "Good" (Score:2, Informative)

    by mykepredko ( 40154 )

    This type of article comes up continuously on /. and without some concrete defining attribute asking what model/version/etc. of "X" is "Good" is going to turn into a poll.

    I would consider "Good" code to have the following attributes:
    1. Runs under all operating systems and platforms
    2. Source code is readable (note, this does not mean "Well Commented")
    3. Takes up the minimum amount of space
    4. Operations execute either apparently instantaneously or provides a progress bar for the user
    5. Installs quickly
    6. It's

    • "1. Runs under all operating systems and platforms"

      Nothing like starting out of the gate with impossible to achieve goals.

  • diversity! (Score:4, Funny)

    by digsbo ( 1292334 ) on Friday March 27, 2015 @02:44PM (#49356433)
    When it's written by a gender and race balanced team, in a positive, multicultural environment, then it's good code!
  • by Karmashock ( 2415832 ) on Friday March 27, 2015 @02:48PM (#49356471)

    That is... as brief as it can possibly be to accomplish the stated goal. Very simple.

    I also like it when the code is commented properly so that every operation is broken down and and annotated to explain what it is doing.

    This lets me go through the whole program and see what it is doing and the way it is doing it very quickly.

    The code that makes me crazy is the rube goldberg code that does some thing very simple in the most elaborate way possible, has no annotations so I have no idea what the actual point of the code is, and then to make things worse various parts of the code will randomly switch between doing different things for no reason.

    THAT code I hate. I see that shit and I delete it and write over myself.

    Part of the problem is that people don't know how to do somethings. They understand the language but they haven't memorized the really short code snippets that are the ideal way of getting from point A to point B. And that's just something a programmer should either have memorized or stored somewhere for recall.

    Using those code snippets tends make the code far more elegant and much more readable because you can see beyond the annotations what they're doing because you recognize that snippet.

    If they never use them, that is fine too... just so long as they don't make their code look like that breakfast making machine from Chitty Chitty bang bang. If they do that, I will murder them all. :-D

  • ...not having your fucking article spread across 9 pages with about one paragraph per page. That would be a great start!
  • Time (Score:4, Insightful)

    by El_Muerte_TDS ( 592157 ) on Friday March 27, 2015 @02:50PM (#49356487) Homepage

    After 5 years you can still read it and understand what it was supposed to accomplish, and it does so.

    • Scrolled down for this. I would add, "time and testing" and "testing" usually involves wide distribution. Yes, JPEG, PNG and Open Source compression libraries have had bugs, sometimes very serious ones. I still consider it some of the best code out there. I don't think being able to read the code matters. That's a red herring, unless you need to work on it. If everybody needs to work on it, it's too unfinished to be particularly good code. The only thing I've read in some of these libraries is the he

  • Simple (Score:4, Insightful)

    by Elixon ( 832904 ) on Friday March 27, 2015 @02:52PM (#49356521) Homepage Journal

    I would definitely add "simple". Everybody can write complex code but it takes experience and great knowledge to be able to choose the best fit for the implementation. More experience and knowledge you have more options to choose from. Beginner will usually go with the first hunch that will get complex sooner or later as he will meet challenges he didn't expect...

    So yeah, simple, readable, documented, functional, consistent...

  • Seriously. Good, readable names for everything make code far more self-documenting than otherwise, don't cost the compiler a single cycle, and make it far easier to understand when someone comes across it five years down the road.

    Other than that, I'd add methods that only perform one action, with no side effects, and that only work at one level of abstraction.

    Finally, code that matches its method name - don't say "if thing.checkValues()", say "if thing.isValid()" - and if isValid() does anything like trimm

  • It's not that hard. (Score:4, Interesting)

    by paavo512 ( 2866903 ) on Friday March 27, 2015 @02:56PM (#49356569)
    Good code has documentation for knowing what it should do, and has unit tests to verify that it actually does that. If there are any problems good code can be modified to meet the (possibly changed) requirements better, while unit tests ensure the modifications do not make the code worse. Code which cannot be modified is not good code. It's that simple.
  • I don't care how bad or tangled the logic but as long as it's not using Hungarian notation [], It's good.

    • by Livius ( 318358 )

      Hungarian notation was fabulous for its intended purpose: code that mixed C and assembly language.

      Sadly it escaped.

  • by gestalt_n_pepper ( 991155 ) on Friday March 27, 2015 @03:13PM (#49356715)

    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.

    • Techno-machismo teens playing games trying to get their code into the least number of characters and the least amount of memory.

      Given how many programs I've used over the past decade that have required unreasonably high amounts of RAM, and/or were subsequent releases of software that solved a particular problem in earlier iterations but required 1/10th the memory to do it, I wouldn't mind a handful of these guys getting their desks back. Adobe is a great place to start.

      I've had to fix or test so much of this junk and it's still just plain stupid.

      I'm by no means a programmer, but from the handful of times I've seen what you're talking about, I'll say this: if it's possible to save 10% of RAM by shifting the ea

  • One of the most important criteria is that good code be easy to modify. Readability, testability, elegance, and simplicity all lead back to that. When you change code, you should be assured that it will do what you expect. Bad code produces surprising side effects when you change it. Good code warns you (possibly through unit tests attached to the code) when you are doing something questionable. If you have to run the code to determine what it does, then that's not good code.

    Needs evolve and change ove

  • by PPH ( 736903 )

    Spaghetti code is good.

    With lots of meatballs.

  • Coding a prototype of something that's rapidly changing in huge ways should be done differently than production code that's worked on by lots of different developers. One will not be optimal for the other.
  • The Wayback Machine...

    Or, see the Slashdot article, "Beautiful Code Interview []" that discusses an entire book about the very topic.

  • I agree with most of the earlier posts, but the main thing I look for is conciseness and clear & consistent naming of variables. If your methods/procedures/classes/functions/subroutines are are obnoxiously long, it makes it less readable, harder to test, and just longer to debug. Modular design also lends itself to be more reusable. I've always been of the mindset to name your variables what they are. You shouldn't have to go to a comment or read the code to see what it does. It should speak for itself
  • Code has to be AVAILABLE - this is the most important. That means it must be OPEN SOURCE.

    If it is CRAPPY code, it can be MADE BETTER if it is open source.
    If it is INEFFICIENT code, it can be REWRITTEN if it is open source
    If it is HARD TO UNDERSTAND code, it can be COMMENTED if it is open source.

    So any code that is OPEN SOURCE, even if it is crappy, inefficient and hard to understand, can be improved.

    But any code that is CLOSED is absolutely useless in my opinion.

    • Functions that span 1000 lines with heavily nested if and switch statements and behaves differently depending on global variables
    • Massive 10k line classes that are more mystifying than God himself
    • Everything is an interface because you may want to create a mock for it, and you get multiple inheritance!
    • No comments. Code essentially comments itself!
    • Functions should create side effects, otherwise life would be boring.
  • ... functional, readable, testable ...

    From the maintenance perspective, when you can't make the code meet some standard, comments describing what you missed and why (time, spec conflicts, didn't care enough) are helpful. This hints to the next maintainer that modifying a piece of code that missed some good-practices target has additional considerations or hidden pitfalls, or that it can be fixed/extended/replaced with impunity.

  • Good code has comments for edge cases, I mean "why the fuck are you checking if foo is less than bar?" with "//checking if foo will not overflow because ..."

    Edge cases are by definition very unlikely, usually the code that handles them are bugfixes. Too many times I come across code that is full of bugfixes for those edge cases but no comments whatsoever, to me those kind of comments are more important than method comments (aka javadoc).

  • Elegance.
  • There are several metrics which can help you to identify code which is not bad. One is cyclomatic complexity. Another are connectivity metrics going over the graph your code spans. For cyclomatic complexity there are good boundaries available. However, it is a complexity metric. And complexity is not the only thing which affects code quality. Other elements are labeling operations, such as methods, functions, and procedures. There is plenty of lit. available in the area of code comprehension.

  • If the code has a useful function and exposes it with an interface that is no more complex than absolutely necessary, it doesn't matter how ugly it is inside. It will be used and, in time, there will be resources to clean it up. UNIX system calls, libraries and command line tools are a good example. There is not much in common between original code and various modern implementations, but code written on top of these over decades still works and both developers and users are able to leverage their experience

  • by TeknoHog ( 164938 ) on Friday March 27, 2015 @06:46PM (#49358249) Homepage Journal

    A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

    -- Antoine de Saint-Exupéry

  • Code needs to be easy to understand, that's all. You can't keep a long list of priorities in your head, that simply doesn't work at all. Just keep one: easy to understand.

    Of course it needs to work, but that's obvious so not really worth stating - testable is part of this obviousness, if you need to test it, and you can't, well, then it doesn't work.

    Sometimes code needs to be performant, but often this is only the case for small parts of it, so it's better not to think about it or it will tend to compete wi

  • by TMB ( 70166 ) on Saturday March 28, 2015 @02:59AM (#49359909)

    The best piece of code I ever wrote in my life was nearly 100x faster than the next best algorithm ever written to do that problem. That took the expected run time down from a few days to an hour.

    It was not a particularly well-commented piece of code. If it were, it would have been even better.

    It was not a particularly obvious algorithm for solving the problem. If it were more obvious why one would choose to do it this way, it would have been even better.

    If the primary concern is runtime (because it normally takes days to run), and you literally make it orders of magnitude faster, that's good code. It could be better if it were also better commented and easier to maintain, but those aren't *always* the primary concern (yes, sometimes they are. That's the point -- criteria differ!)


Civilization, as we know it, will end sometime this evening. See SYSNOTE tomorrow for more information.