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

 



Forgot your password?
typodupeerror
Programming

Ask Slashdot: What Do You Consider Elegant Code? 373

Posted by Soulskill
from the link-it-if-you've-got-it dept.
lxrslh writes: "Since the dawn of computing, we have read about massive failed projects, bugs that are never fixed, security leaks, spaghetti code, and other flaws in the programs we use every day to operate the devices and systems upon which we depend. It would be interesting to read the code of a well-engineered, perfectly coded, intellectually challenging program. I would love to see the code running in handheld GPS units that first find a variable number of satellites and then calculate the latitude, longitude, and elevation of the unit. Do you have an example of a compact and elegant program for which the code is publicly available?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Do You Consider Elegant Code?

Comments Filter:
  • Duff's Device (Score:5, Informative)

    by smitty_one_each (243267) * on Wednesday March 26, 2014 @04:05AM (#46582153) Homepage Journal
    Duff's Device [wikipedia.org]
    • Re: (Score:3, Informative)

      by Anonymous Coward

      Uh... that Wikipedia article shows 3 lines of code, which it describes as "straightforward":

      Straightforward code to copy items from an array to a memory-mapped output register might look like this:

      do { /* count > 0 assumed */
      *to = *from++; /* Note that the 'to' pointer is NOT incremented */
      } while(--count > 0);

      Then this reference implementation of Duff's device:


      send(to, from, count)
      register short *to, *from;
      register count;
      {
      register n = (count

      • by DpEpsilon (2538466) on Wednesday March 26, 2014 @04:35AM (#46582271)

        When numerous instances of Duff's device were removed from the XFree86 Server in version 4.0, there was an improvement in performance

        Personally, I blame the compiler for failing to optimize properly.

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          Is this a joke? The reason Duff's Device is no longer any faster is because the modern compiler is able to optimize properly.

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          Manual optimizations such as Duff's Device usually prevent the compiler from doing automatic optimizations because the effects of the code becomes obscured.

      • by DrJimbo (594231)

        According to the reference, the reason for the speed improvement had to do with the vastly different CPU architecture and specifically with getting more cache misses due to an increase in the size of the code base because of the unrolled loops.

        It seems rather silly to imply that Duff's device is no longer elegant merely because it does not apply to current CPU architectures.

        • Re:Duff's Device (Score:5, Insightful)

          by BasilBrush (643681) on Wednesday March 26, 2014 @06:42AM (#46582725)

          It's not elegant because it's a dirty optimisation taking advantage of two inadequacies of C: The horrendous fall through behaviour of switch statements, and the lack of a requirement for proper nesting of control blocks.

          The original code is far more elegant than DD.

          Put it another way, the only reason for using DD rather than the original is that it was quicker on non-optimising compilers. Not that it was graceful, nor stylish, nor simple.

          The fact that it's slower than the original code now makes it even less of a qualifier. It's now an optimisation failure. Something that needs to be removed to optimise.

    • by Viol8 (599362) on Wednesday March 26, 2014 @04:51AM (#46582321)

      IMO elegance comes with simplicity and duffs device actually makes the simple fairly complex, at least from a syntactic point of view. Mind you, compared to the unintelligable contorted rubbish calling itself C++ that I've had to debug over the years its a masterclass in clarity. Anyone who suggests building a framework for any project that is going to take less than a week should be shot on the spot.

      • by Bongo (13261)

        Time. Good point. Many building architects defend bad designs with, "but that's all the time we had."

        Either the original developers have time to iterate to a cleaner design, or the maintainers have to do it, or the original developers had lots of experience with similar frameworks that they already have better designs in mind—acquired over time.

        • I don't think that's what he meant. I think he says that anybody who manages to add complexity to something simple and straightforward (a project that would only take a week to do) by adding "beautiful" layers that provide abstractions for the sake of abstraction, should be shot. Personally, I would happily set fire to the remains after the firing squad had its turn.

    • That's a neat trick, but is it elegant? To me, elegance at code level means succinct and readable code. Optimizing for performance usually comes at a lower level of readability.

      Look at the examples from that article:

      do { /* count > 0 assumed */
      *to = *from++; /* Note that the 'to' pointer is NOT incremented */
      } while(--count > 0);

      Compared to Duff's optimization:

      send(to, from, count)
      register short *to, *from;
      register count;
      {
      register n = (count + 7) / 8;
      switch(count % 8) {
      case 0: do {

      • To me, elegance at code level means succinct and readable code. Optimizing for performance usually comes at a lower level of readability.

        Therefore, first write the code in the most elegant way.

        Then, write an optimizer that optimizes that code. Of course, the optimizer itself should be elegant, but it need not be efficient.

    • If you call that "elegant", I wouldn't want to see your own code. I'd submit it to thedailywtf.com if it wasn't that old.
    • by Phoeniyx (2751919)
      There is nothing elegant about this. It's complicating something much more readable. Granted, elegance is related to simplicity, readability, AND efficiency - among others.. However, efficiency should not trump the other attributes - that's the job of the compiler. It's best not to confuse the roles of the two: the programmer and the compiler.
    • Re:Duff's Device (Score:5, Insightful)

      by gweihir (88907) on Wednesday March 26, 2014 @05:50AM (#46582519)

      Fail. Elegant != Complicated.

      This is a common fallacy which makes many programmers think they are great but they are really are abysmally bad. Code has to be readable! Here is something that gives the idea:

          There are two ways of constructing a software design: One way is to make it
          so simple that there are obviously no deficiencies, and the other way is to
          make it so complicated that there are no obvious deficiencies. The first
          method is far more difficult. --Tony Hoare

      Most programmers considering themselves "good" fail this test and go for the second option.

      • Re:Duff's Device (Score:5, Insightful)

        by Viol8 (599362) on Wednesday March 26, 2014 @07:07AM (#46582839)

        Wish I had mod points. In seems to be a badge of honour for some coders to make their code as obfuscated as possible. I'm not sure who they're trying to impress but it sure as hell isn't the poor maintenance coders a few years down the line.

        • by Anonymous Coward on Wednesday March 26, 2014 @08:44AM (#46583495)

          ...I'm not sure who they're trying to impress but it sure as hell isn't the poor maintenance coders a few years down the line.

          I write simple code. I am primarily a C/C++ coder and in the "Obfuscated 'C' contest", I wouldn't even make the cut.

          My code was described as very "simple" in a patronizing tone. My code works, has very very few bugs, it is done on time, and looking back at it after year, you can see exactly what it's doing - even without reading the many many comments.

          I was treated as the dullard of the team. It's like if you don't use all the tricks and shortcuts, somehow you don't really know the language that you are programming. And if your code is too easy to understand, then you are not as smart or good.

          I started in this business in 1992 and I have never been in a shop that did not have the attitude.

        • Re:Duff's Device (Score:4, Insightful)

          by Anonymous Coward on Wednesday March 26, 2014 @08:57AM (#46583589)

          Many moons ago I refactored a complex function by a much respected 'Master Programmer'. "It's going to take you a good few years before you're at his level", they told me. After I had finished refactoring his function, a page and a half of heavily nested if/else statements had boiled down to a single CASE statement, 4 lines long, doing the exact same thing that his original code did.

          In my book, this guy wasn't a Master Programmer at all. He overcomplicated things. His code was unmaintainable to anyone but him - and evidently he had a pretty hard job maintaining his own code.

          Elegant code is code that correctly solves a particular problem in the simplest possible way. Bonus points if minimal CPU/Memory resources are used to achieve that.

  • by Xouba (456926) on Wednesday March 26, 2014 @04:12AM (#46582173) Homepage
    The Linux Kernel is a fine example of public mammoth project with strict style guidelines, and ones that are quite elegant IMHO.
    • Re:Linux kernel (Score:5, Insightful)

      by Anonymous Coward on Wednesday March 26, 2014 @04:21AM (#46582201)

      The common definition for elegant code is. "Anything not written by someone else."
      In general code tends to be an ugly patchwork until you refactor it, introduces a couple of bugs, fixes the bugs and ends up in the starting position. The big change is that you now realize why the "ugly patches" were an elegant solution to the problem.

      Or to phrase it differently; elegant code is code that has enough comments to explain why it isn't possible to make it simpler.

      • Re:Linux kernel (Score:5, Insightful)

        by gmack (197796) <gmack&innerfire,net> on Wednesday March 26, 2014 @07:14AM (#46582877) Homepage Journal

        I strongly disagree with this. While I admit that elegant code can have ugly portions refactoring will often be an improvement but the trick is to learn when refactoring will help and when it will be a waste of time. The worst programmers I know are the ones who say that "I don't have time to go back through my code". I have cleaned projects where the original coder did the same thing three different times or reinvented the wheel when there were better libraries. In fact, I have been also guilty of this and even in my own projects I have come across places where the requirements changed out from under me mid project or I simply see better ways of doing things as I gain experience.

        Elegant code:
        1 Handles errors gracefully
        2. Only reinvents the wheel when there is a measurable benefit in doing so.
        3. Has consistent naming conventions.
        4. Has comments around ugly code explaining why it is ugly.
        5. Compiles (or runs if interpreted) without warnings.

        • Re:Linux kernel (Score:5, Insightful)

          by Greyfox (87712) on Wednesday March 26, 2014 @08:30AM (#46583397) Homepage Journal
          Ooh, I like this list! My usual MO is to (try to) write reusable libraries for most of my project and glue the library code together with a main program that does as little extra processing as possible on the library objects. If I'm writing a library, I like to add the extra criteria that it to be easy for a programmer to pick up and use. The actual library code can be absolutely hideous but if it gets the job done and the interface is easy to use I'm not going to complain about it.

          I've been coding for the fun of it again in my spare time, and have a fair bit of code up on GitHub [github.com] now. I've only been seriously using C++ for the last couple of years, and you can see a bit of a progression from my early code (fr_demo) to more recent code like the data library and resumetron. Stuff like cppxml which I use frequently gets updated more often than the old demo code.

          I particularly like my factories. I have a relative going through a CS program right now and he's had some questions on a couple of his assignments and got a look at a piece of code with data readers provided by his professors. They always look like C code that was written 15 years ago. I know this because I also very recently was digging through some C code that was written 15 years ago. I like to think they're doing that on purpose, but they're not. So his introduction to design patterns could have been a nice clean data factory that requires three lines of code to write, but instead it's the singleton pattern, which every design review board on the planet will now reject immediately after the word leaves your mouth, whether it's actually justifiable or not.

          One of these days real soon now I'm going to need to go back and replace all my std::string throws with std::logic_errors or other appropriate std::exception errors, and I'm kicking around the idea of building up a simple rest server around my old socket server code one of these days. That sounds like fun to me!

  • by korbulon (2792438) on Wednesday March 26, 2014 @04:13AM (#46582175)

    or is the OP requesting us to hunt down a piece of code that fulfills his project specs (and does it elegantly, gosh darnit!)?

    Is the OP's real name Tom Sawyer?

    • by mwvdlee (775178) on Wednesday March 26, 2014 @04:31AM (#46582251) Homepage

      The request is oddly specific.
      It might be more prudent to ask for particularly nice before- and after refactoring examples in general.

      I love the elegance of object oriented parser frameworks (disclaimer; I've made several myself), but that elegance is rather in the model than the code.
      Elegance purely in code I can only really remember seeing in small functions and snippets. Mostly elegance seems to be in the structure and interaction between functions or objects.

      • by Joce640k (829181)

        The request is oddly specific.

        Yes. Very odd...

        Almost like a code request.

        The correct thing to do would be to find one then add a very sneaky flaw. Find out if all he really wanted was to "read" it.

      • by bertok (226922)

        It might be more prudent to ask for particularly nice before- and after refactoring examples in general.

        Seconded!

        I once saw a Java class with pages of complex multi-threaded code to update the horizontal offset of the ticker in a GUI. Not counting the usual minimum content of a class file, I replaced it with a single line along the lines of "return velocity * getCurrentTime();". So satisfying! 8)

    • by lxrslh (652069)

      or is the OP requesting us to hunt down a piece of code that fulfills his project specs (and does it elegantly, gosh darnit!)?

      Is the OP's real name Tom Sawyer?

      OP Here: I am a retired Assembler 360 programmer. I have no project needs or other reason for my specific example, which was merely an example of what I suspect/hope is an elegant program. I could be wrong about that. Feel free to discard your understandable cynicism.

      • by korbulon (2792438)

        Ha HA! Ya got me. .

        At this stage in the game I don't know where the cynic ends and the human begins.

        "Probably at the asshole," a voice whispers in my ear.

      • And you didn't post IBM Assembler macro language?

        The BAL Macro language could do things that C++ template functions can't. You could test *all* of the attributes of a parameter, from datatype through number of characters in the name, and vary the generated code accordingly - amazingly powerful levels of abstraction when used properly.
    • by Chrisq (894406)

      or is the OP requesting us to hunt down a piece of code that fulfills his project specs (and does it elegantly, gosh darnit!)?

      Is the OP's real name Tom Sawyer?

      Do we have to pay to join in?

  • Writing code can be like explaining something or teaching. You can give an explanation that is logically correct but difficult for a human to follow. Programmers tend to neglect this in their code because it can be difficult to construct something that reads well and even if it doesn't read well, it can still be executed by a computer.

    I like to think that if code is 'elegant', it can be read well after at most after brief explanation of how the algorithm is supposed to work, because code alone is sometim
    • if code is 'elegant', it can be read well after at most after brief explanation of how the algorithm is supposed to work

      exactly my thoughts as well.

      all "code" is symbols arranged to communicated **instructions** to a machine

      it's all instructions...the variation is the way the instructions are delivered

      knowing this, and having some experience coding, elegant code will be understandable to even novices once the basic "language differences" are learned

    • by mooingyak (720677)

      Writing code can be like explaining something or teaching. You can give an explanation that is logically correct but difficult for a human to follow. Programmers tend to neglect this in their code because it can be difficult to construct something that reads well and even if it doesn't read well, it can still be executed by a computer.

      I like to think that if code is 'elegant', it can be read well after at most after brief explanation of how the algorithm is supposed to work, because code alone is sometimes difficult to interpret.

      Similar to my thoughts. There are levels of elegance. The minimum requirement is that it does what it's supposed to, that something is non-trivial, and the code is fairly easy for anyone familiar with the language to understand. Better is when it does all that without any prior explanation of what it's supposed to do. Even better is when the something it's doing is actually quite complex, but still easily understood.

      And then there's just plain awesome, where it uses a language feature that the reader ha

  • by bre_dnd (686663) on Wednesday March 26, 2014 @04:18AM (#46582187)
    Interesting code, serves a real purpose, solves a real problem.

    A lot of "real world" code out there has not been designed, it has grown, and that's part of the problem. Think of cities that have grown (London?) rather than be designed according to some grand master plan (New York?) and major reengineering exercises need to be undertaken (in the case of London, as one example, sewage pipes were fitted in underneath). Inevitably there's some shortcuts taken or real reasons that you could not quite do the best job.

    Codewise, the oldest running code probably lives in the banking system or the telephony system. Typically code that has grown over time and can't just be shut down for an upgrade -- "what do you mean close the bank for a week?". Now whatever code runs there has been kept running (bodged?) for decades, but pretty it probably isn't.

    • by korbulon (2792438)
      In a way these codebases evolve a lot like DNA, and for pretty much the same reasons. So you end up with a lot of patches and hacks, as well as code sediment: stuff that's basically obsolete but would be too painful to remove. Something about the dirty and relentless nature of reality.
    • by mooingyak (720677)

      Think of cities that have grown (London?) rather than be designed according to some grand master plan (New York?)

      I've never been to London, but I work in NY. It's almost the exact opposite of what you're saying, or maybe the middle ground that you didn't cover. Someone designed it to a master plan.... a long time ago. And then it grew. Nowadays I joke that if you're designing a city and your major highways look anything like NYC, it's time to fire the designer.

  • by Big Hairy Ian (1155547) on Wednesday March 26, 2014 @04:20AM (#46582191)
    Just like everyone else
  • by Asteconn (2468672) on Wednesday March 26, 2014 @04:22AM (#46582205)
    I consider code elegant if I can read it and understand it on the first try, personally.
    • I consider code elegant if I can read it and understand it on the first try, personally.

      This is a good barometer.

      When I write code, my goal is to create an accurate design with the proper abstractions that will make the complex business problem look like it was trivial to solve. The easier that I made my job look, the higher the quality of my deliverables, in my mind. The next person to look at my code should say, "Of course he solved the problem that way. I would have done the exact same thing."

      By the way, given the sheer volume of WTFs I encounter, the next person to look at my code probably

    • by Tablizer (95088)

      Some engineers consider code "elegant" if it's factored to the smallest possible form, which generally means all repetition possible is factored out.

      But such code has at least two problems. First, is that it may not be easy for a good portion of developers to read and understand. Factoring out all possible duplication often results in a lot of indirection (reference levels), and indirection can slow down and complicate reading because you have lots of small parts referencing (using) lots of other small part

  • by petes_PoV (912422) on Wednesday March 26, 2014 @04:26AM (#46582225)

    Most code will not fall into the "elegant" category. The reason is that real-life software has to deal with exceptions, language crocks, patches/modifications and bug-fixes. It is also subject to the constraints, limitations and ugliness of whatever it has to run on and interface with (no program is an island entire of itself Every program is a piece of the continent, A part of the main() [ John Dunne] ).

    Therefore the only place you'll find elegant code is in a book about algorithms, where the idea is presented in isolation and not subject to the practicalities of real-world environments

    • by twdorris (29395)

      Most code will not fall into the "elegant" category. The reason is that real-life software has to deal with exceptions, language crocks, patches/modifications and bug-fixes.

      And those damn users. I can write what I (and seemingly others) consider "elegant" code. But that's usually only possible down in the bowels of a microprocessor where you have known constraints and no meat bags randomly typing shit at you that you have to parse and decipher and then present a myriad of exception messages back to, etc., etc.

    • Yes, but try to explain that to a manager, or to a user!

    • by JaredOfEuropa (526365) on Wednesday March 26, 2014 @05:32AM (#46582463) Journal
      At the code level, elegance means readability and ease of understanding what is being done, it's not about the code lines being pretty or poetic. If you have to use a crappy workaround or do some non-obvious API calls because the API you code against is crap, you add comments to explain what you're doing, and try to contain each "hack" to one function or method (rather than designing your objects around them). That way, you can keep your code readable and understandable, and elegant.

      At the data / object model level, there are good real-world examples of elegant coding. At this level, elegance affords the ability to make smaller changes or bug fixes without having to resort to major refactoring or adding a lot of messy code in many different places in your program. At this level, elegance also works to isolate the overall program from ugly interfaces / APIs.
      • by gstoddart (321705) on Wednesday March 26, 2014 @07:48AM (#46583101) Homepage

        At the code level, elegance means readability and ease of understanding what is being done

        And maintainability. People often forget that one.

        I once had a co-worker who wrote a component he thought was elegant, because it had a nice lovely modelling and abstraction and matched how he thought the problem should be solved.

        The problem was, his solution was rigid, brittle, and kinda wrong. The things he turned into elegant objects didn't behave that way, and the things he didn't were the actual meat of the problem.

        Every time he had to fix a bug or add a change, he spent time trying to understand how his code worked, where he'd have to make changes, and then bitching about how the change violated his nice 'elegant' code.

        On another project, he was writing a component which consumed stuff from a component I and another co-worker had built (they were built concurrently).

        By the time we were ready to do integration testing, his nice elegant code had been built on the assumption we would implement all of the semantics for his part (which we couldn't possibly have known). He had structured his code in such a way as to be 'elegant' as long as the library he was using had behaved in a way that nobody would have modeled unless it had been written to precisely implement his semantics.

        And, again, his 'elegant' code was rigid, brittle, and wrong and had to be significantly changed to work with an interface he knew about in advance, because we'd agreed upon it before writing both pieces.

        At the data / object model level, there are good real-world examples of elegant coding. At this level, elegance affords the ability to make smaller changes or bug fixes without having to resort to major refactoring or adding a lot of messy code in many different places in your program.

        And if you start with a terrible object model and then write elegant code around that terrible object model, you get the exact opposite.

        And then don't get me started on trying to make your 'elegant' code go faster because you've created more work with how you've structured your code.

        Once had a coder tell me we shouldn't optimize because computers are Really Fast and we probably can't do any better. Then I threw away a large chunk of his code and replaced it with something which wasn't doing silly things, and we got a giant speedup.

        Some people get so damned focused on writing what they think is 'elegant' code that it is neither useful to the task, well written, nor maintainable.

  • GPS code (Score:4, Informative)

    by tlambert (566799) on Wednesday March 26, 2014 @04:39AM (#46582275)

    http://www.gpstk.org/bin/view/... [gpstk.org]
    http://www.rtklib.com/ [rtklib.com]
    http://gnss-sdr.org/ [gnss-sdr.org]

    Next time do your own google search.

  • by Wowsers (1151731) on Wednesday March 26, 2014 @04:43AM (#46582289) Journal

    I don't know if it counts as "elegant code", but I find it really useful that code is fully commented. Speaking for myself, it's useful to come back months or years after originally writing code, and knowing why I wrote such a routine the way I did, and what it does, making changes easier and quicker.

    • by pr0nbot (313417)

      My rule of thumb is, "if the first implementation of this didn't work, and I had to change it, then it needs comments" on the principle that if the "obvious" solution turns out not to work, then the problem is not as obvious as I'd thought.

  • by igomaniac (409731) on Wednesday March 26, 2014 @04:48AM (#46582313)
    • You may have been joking, but this one is fantastic: http://www0.us.ioccc.org/1988/... [ioccc.org]

      It calculates pi by measuring the area of an ASCII circle, which is an incredibly direct encoding of the problem. Other than that there are two lines of supporting boilerplate and a couple of braces.

  • Minimise state (Score:5, Interesting)

    by famebait (450028) on Wednesday March 26, 2014 @04:54AM (#46582327)

    You always have to keep in mind that code will be changed by serveal peopale, and your 'elegant' intention may not be understood or followed through by the next guy. So go for simple rules of thumb that not only keep your code readable and clear, but can accommodate future change while ramaining so.

    My number one rule for keeping code both readable and robust is this: Reduce state.

    I don't mean everything needs to be purely functional, but consider state a general liability to both correctness, readability, testability and maintainability. Less is more..
    * Whatever state you have should be focused and serve to explain/model the actual problem domain, not just 'keep stuff for later'.
    * Keep state as local as possible - most code is litered with instance variables that should have been locals and params.
    * Just because an object _can_ bundle state with its functions doesn't mean it _should_.
    * If it can be done in a static method and still make sense, do so.

    • In general, the best you can do in terms of simplicity is to write code that computes the result (e.g., the "current" observable state of an interactive program) from scratch at every instant. However, this would make the code needlessly slow. You are then forced to cache stuff, etc., and things become ugly...

      • True. But bear in mind that one shouldn't optimise early. So if one took the idea that state is bad, one could always compute the result rather than cache for the initial implementation. Then only cache where profiling indicates there's an issue.

  • by GrahamCox (741991) on Wednesday March 26, 2014 @05:15AM (#46582391) Homepage
    New code is always elegant at first. But invariably it doesn't work properly, and by the time you have got it to work, it's no longer elegant.
    • by Lumpy (12016)

      This depends. if there is no idiot manager breathing down the neck and allows the programmer to take the needed time to test, rewrite, test, rewrite... then the output is good code.

      Loser managers that cut in half or worse in third the time it takes to actually write good code cause most of the horrid crap you see out there. I guarantee that everything written by Bioware is an unholy mess. The sheer number of bugs I see in every one of their releases means they dont care about good code, they care about th

      • by asylumx (881307)

        allows the programmer to take the needed time to test, rewrite, test, rewrite...

        Real developers ship. You are working for a business; you are not doing an academic study.

        The sheer number of bugs I see in every one of their releases means they dont[sic] care about good code

        And here we have another problem. You think that good or elegant code means bug-free. It doesn't. There's lots of pretty code out there that doesn't do what it's supposed to do.

  • by Balinares (316703) on Wednesday March 26, 2014 @05:16AM (#46582393)

    Maybe you've been lucky enough to have that once in a lifetime great teacher. The kind of teacher who somehow explains stuff in such a way that everything makes sense to you; things follow logically from one another and it all seems obvious when he explains it. (And you may not even realize it until he falls sick and the substitute trying to explain the exact same stuff leaves you confused and baffled.)

    Elegant code has the same property of apparent obviousness. You read it and just nod because it makes sense and flows logically. There isn't one single way to achieve this, of course. It's not about functional vs. imperative vs. object oriented, but how you employ them for clarity.

    Needless to say, such clarity is a very hard property to achieve, and a lifetime of experience will only let you approach it asymptotically. It's still worth the attempt, though.

  • by CockMonster (886033) on Wednesday March 26, 2014 @05:47AM (#46582507)
    The first thing I look at when looking at interview candidates code is their style. I don't care particularly if it's not the same as mine, but I do care if there's no consistency to their own style. I'm talking about hurried formatting, trying to squeeze everything into the least number of lines, mixed naming conventions, bad spelling in comments, even down to things like inconsistent spacing. Maybe I'm a prude but if I'm going to be looking at this person's coding output all day it better at least be readable. That Linux managed to maintain a consistent coding style with so many contributors is an admirable feat. As for beautiful algorithms, I quite like the simplicity of Dijkstra's shortest path.
  • Elegant code is code you can look at and understand what its doing and then audit easily.

    That is the real point of elegant code. You ACTUALLY know precisely what it is doing. No guess work. The best code can be understood with a casual glance and any mistake in the code stands out brightly because the pattern and elegance of the code is beautiful in its way. And any imperfection is ugly.

  • by Lumpy (12016) on Wednesday March 26, 2014 @05:52AM (#46582531) Homepage

    Code that does the job in the simplest possible way. This means that the writer went through several prototypes before they settled on the code they liked instead of the normal..."it works SHIP IT!"

    No obfuscated crap, it's clear simple and concise.

  • by Jahta (1141213) on Wednesday March 26, 2014 @05:58AM (#46582543)

    If you follow the principles and practices in Clean Code: A Handbook of Agile Software Craftsmanship: Robert C. Martin [amazon.com] you won't go far wrong. It also includes a worked through example of refactoring a piece of bad code into clean code.

  • My personal "law" (Score:4, Insightful)

    by acroyear (5882) <jws-slashdot@javaclientcookbook.net> on Wednesday March 26, 2014 @06:21AM (#46582623) Homepage Journal

    Code written to do one thing is inherently elegant.

    No code ends up ever having to do one thing.

    The job of requirements gathering is to determine what are the constants and what are the variables. In the case of, say, GPS, the constants should be the protocol of the satellites, the max and min # of sat's that can be found at any given time, the grid representation of the earth, and the system clocks.

    Nice and easy, right?

    Now change all of those to a variable: you have satellites speaking to you in different protocols based on their age. You end up with only one sat connection so no triangulation due to mountain or building blockage. The grid representation of the earth is inherently distorted at the north and south extremes (and whenever you're above 5,000 feet). Oh, and the you forgot to time-distort your own clock for the rotation of the earth, so a tiny offset is being caused by General Relativity.

    Suddenly code that was nice and simple is now full of ifs and switch loops and complex adjustments and bits of guess work and comments that say "oh, well, we'll just have to ignore that last part...but we'll only be off by 30 feet or so".

    The first bug in software happens when something that was presumed in the requirements to be a constant has to be changed into a variable. Every bug that follows is a result of trying to fix that first bug.

    Because of that requirements problem, no working production code can ever be elegant.

  • There is an instance of elegant code that solves a real life engineering problem that beats the competition by orders of magnitude in speed, resource usage, robustness and accuracy.

    Unfortunately my employer thinks it belongs to the corporation, because they paid me something they call salary to me when I wrote it. They would not let me show it to you all. But this much I can tell you. The key to writing such wonderfully elegant code is to avoid exaggeration, stay away from bragging, and most importantly e

  • FORTH (Score:5, Interesting)

    by Giant Electronic Bra (1229876) on Wednesday March 26, 2014 @07:55AM (#46583141)

    A complete highly extensible interpreted language with a built-in editor, macro assembler, etc in under 10k lines of code which did everything any modern scripting language does, except they all require at least 200KLOC to do it in.... This is the most elegant piece of software ever written, bar none. It isn't even a contest.

  • by plasticsquirrel (637166) on Wednesday March 26, 2014 @08:22AM (#46583323)

    Elegant code is...

    • Simple -- leveraging the "natural" way to use the programming language
    • Compact -- not cluttered with special cases and boilerplate
    • Logical -- like secondary documentation, acting as a clear description of how to solve a problem
    • Modular -- functions or classes should be clearly grouped as modules
    • Easy to understand -- not full of stupid hacks and "clever" tricks
    • Reasonably efficient -- performing reasonably well, not at the expense of simplicity
    • Maintainable -- any decent programmer could pick up the code without fear and trepidation
    • Commented -- some comments should be present, but not too much
    • Correct -- it should do what it is meant to do, and only this

    There are also some languages that I view as inherently elegant, and others that I consider not to be so. C, Python, and Ruby all allow breathtaking elegance in their own way. C with its spartan manner of managing the machine, Python with its ridiculously readable pseudocode-like syntax, and Ruby with its pure object system and powers of abstraction. On the other hand, some other languages like C++, Java, Haskell, Javascript, PHP, BASIC, and Erlang will never be languages that lend themselves to true beauty and elegance. All of those languages either have serious flaws, or they do not allow programmers to express their ideas eloquently in code. In a good language, your ideas should pop out as the most important thing, not the language itself.

  • by cjjjer (530715) <cjjjer&hotmail,com> on Wednesday March 26, 2014 @08:37AM (#46583445)
    Most of your so called *elegant code* I have seen is either difficult to maintain or performs poorly due to the original developer trying to be a fancy pants. I can count the times on one hand that I have ever said "whoa" when looking at a piece of code.
  • by andawyr (212118) on Wednesday March 26, 2014 @11:13AM (#46584733)

    Fantasic example of code written in a procedural language (C) in an object-oriented way,with clear separation of responsibilities.

    http://www.postfix.org/ [postfix.org]

    The framework that Wietse created to structure Postfix is, from my perspective, a thing of beauty. I don't doubt that this has been done elsewhere, but Postfix is the first real example that I came across of a somewhat-large application structured in a very clean and understandable way.

    Well worth spending some time perusing the code.

  • by Fubari (196373) on Wednesday March 26, 2014 @11:24AM (#46584859)
    I'll recommend a tour guide in the form of John Bentley's Programming-Pearls-2nd-Edition [amazon.com].
    His Programming Perls book does a nice job of putting interesting algorithms and design forces into context and helps the reader understand the pros & cons thereof. Part of the problem with just wandering around looking at things is you don't see the history and decisions that were made leading up to the result; understanding "what" isn't nearly as important as "why".

    Also, the book isn't related the the Perl language; instead it uses Pearl as a metaphor for a small yet beautiful treasure.

    Anyway, check out the Amazon reviews to see if it is worthwhile (I have no vested interest here; I just stumbled across this in a real book store some time ago and found it a satisfying read).
  • by whitroth (9367) <whitroth&5-cent,us> on Wednesday March 26, 2014 @11:39AM (#46585053) Homepage

    I have long said I preferred elegant to clever code. When I get a phone call on Friday, at 16:15, or 02:00 some night, I want to leave on time, or go back to sleep that night, *NOT* spend hours figuring out how this bit of cleverness is broken, or how someone's "the code's more compact!" is suitable for entry in the Obfuscated C contest.

    But to write elegant code, you need to a) know what you're trying to accomplish; b) tell your manager, or whoever, that no, you can't make that kind of major change without their $$$ signoff on a change to the schedule, complete with specing out the change, and its affects on everything else; c) having the time to write, test, and debug the code, and this does *NOT* include drinking a six-pack of Mountain Dew a day, and doing 80+ hour weeks.

    Yes, I *have* had jobs like that. And 70+ or 80+ hour weeks result in a *lot* less "productivity" than the old 40-hour week (and try looking up where that number came from... the name Ford may surprise you in that....).

                                mark "as opposed to managers w/ MBA, who think that you can point and click a good system"

1 Sagan = Billions & Billions

Working...