Loading ...
Sorry, an error occurred while loading the content.

A Programmer's Sixth Sense

Expand Messages
  • Shlomi Fish
    To me it seems that I can take a quick glance at a C code and immediately gather how well it is written, even if I don t understand it. I can t quite explain
    Message 1 of 6 , May 11, 2002
    • 0 Attachment
      To me it seems that I can take a quick glance at a C code and immediately
      gather how well it is written, even if I don't understand it. I can't
      quite explain how I feel that way, but I do.

      I think after you understand everything that goes on in the code, than
      most experienced (and good) programmers can have a good estimate of it.
      But I'm not sure if feeling how good it is, can be explained in some way.

      I'm definetely against "feeling" rather than knowing and reasoning
      assertions. But I suppose some experts can have first impressions that can
      eventually be reasoned, and usually found to be correct.

      I can give various examples. For example, I cannot understand most of the
      code of the Linux kernel, but I know it is well-written, just by looking
      at it. I know that the GIMP is well-written, even though its codebase
      could use a lot of commenting. I looked at a fellow student's code, that
      he prepared for our "Structure of OS" course, and could tell it was awful.
      (even though, this time I understood what was going on there) PySol seems
      well-written to me (at least its game logic), but it usually takes me a
      long time to understand what's going on there, because the code is highly
      OO.

      Regards,

      Shlomi Fish

      ----------------------------------------------------------------------
      Shlomi Fish shlomif@...
      Home Page: http://t2.technion.ac.il/~shlomif/
      Home E-mail: shlomif@...

      "Let's suppose you have a table with 2^n cups..."
      "Wait a second - is n a natural number?"
    • Muli Ben-Yehuda
      ... There is no metric to gauge how well a piece of code is written. It might be nonsense to you, poetry to me, and line noise to someone else. ... You knew it
      Message 2 of 6 , May 11, 2002
      • 0 Attachment
        On Sat, May 11, 2002 at 11:00:45AM +0300, Shlomi Fish wrote:
        >
        > To me it seems that I can take a quick glance at a C code and immediately
        > gather how well it is written, even if I don't understand it. I can't
        > quite explain how I feel that way, but I do.

        There is no metric to gauge how well a piece of code is written. It
        might be nonsense to you, poetry to me, and line noise to someone
        else.

        > I can give various examples. For example, I cannot understand most of the
        > code of the Linux kernel, but I know it is well-written, just by
        > looking

        You knew it was the linux kernel before you looked at it.
        FWIW, some parts of the kernel are horribly written.

        > at it. I know that the GIMP is well-written, even though its codebase
        > could use a lot of commenting. I looked at a fellow student's code,
        > that

        You knew it was the GIMP you were looking at. You expected it to be
        good, and it was.

        > he prepared for our "Structure of OS" course, and could tell it was
        > awful.

        You expected it to be awful, and therefore it was. It's a self
        fullfilling prophecy.

        On a related tangent, big open source projects *have* to be written
        well, since the code is one of the only line of communication between
        the developers. If the code was not well written, the project would
        either wither and die, or get rewritten.
        --
        The ill-formed Orange
        Fails to satisfy the eye: http://vipe.technion.ac.il/~mulix/
        Segmentation fault. http://syscalltrack.sf.net/
      • Chen Shapira
        ... The one consistency I found is that any piece of code *I* write, will look like junk to me in a month. Its natural, I learn a lot in a month... The only
        Message 3 of 6 , May 11, 2002
        • 0 Attachment
          > I'm definetely against "feeling" rather than knowing and reasoning
          > assertions. But I suppose some experts can have first
          > impressions that can
          > eventually be reasoned, and usually found to be correct.

          The one consistency I found is that any piece of code *I* write, will look
          like junk to me in a month.
          Its natural, I learn a lot in a month...

          The only exception is a report generation system, which I wrote half a year
          ago. I've been maintaining this system for 6 month now, and I'm still
          suprised that I wrote something that grows so well.
          After 3 years of writing report generators, I've managed to strike that
          delicate balace between generality and simplicity.

          I found that I'm a very bad judge of other people's code. I can't tell
          anything at all at a quick glance.
          Time after time my first impressions are changed after a week of
          maintainance.
          What looks like a mess at first glance, turns out to be an elegant solution
          to a difficult problem. What looks elegant and impressive, turns out to be
          unmaintainable spagetti of objects and templates.

          IMO the most important things in a program are the functions and objects.
          A function should do one thing well, diffrent functions should work together
          without depending on inner implementation details.
          An object should define a clear area of responsibility, control it well, and
          stay away from the responsibilities of other objects.
          All those things are extremely important, and rarely are they revealed in
          one glance (or ten).
        • Shlomi Fish
          ... I agree that well-written of a piece of code is not a uni-dimensional scalar (i.e: belongs to the R field), but there s still some ways to estimate it. At
          Message 4 of 6 , May 11, 2002
          • 0 Attachment
            On Sat, 11 May 2002, Muli Ben-Yehuda wrote:

            > On Sat, May 11, 2002 at 11:00:45AM +0300, Shlomi Fish wrote:
            > >
            > > To me it seems that I can take a quick glance at a C code and immediately
            > > gather how well it is written, even if I don't understand it. I can't
            > > quite explain how I feel that way, but I do.
            >
            > There is no metric to gauge how well a piece of code is written. It
            > might be nonsense to you, poetry to me, and line noise to someone
            > else.
            >

            I agree that well-written of a piece of code is not a uni-dimensional
            scalar (i.e: belongs to the R field), but there's still some ways to
            estimate it. At least once you are very much familiar with it.

            > > I can give various examples. For example, I cannot understand most of the
            > > code of the Linux kernel, but I know it is well-written, just by
            > > looking
            >
            > You knew it was the linux kernel before you looked at it.

            I don't think that's why I thought so. Many people voice their opinion
            that the Linux kernel is generally well-written, but until then I did not
            know how well it was.

            > FWIW, some parts of the kernel are horribly written.
            >

            Naturally, you can expect this in such a large codebase, with so many
            people writing different parts of the code. Who is John Galt?

            > > at it. I know that the GIMP is well-written, even though its codebase
            > > could use a lot of commenting. I looked at a fellow student's code,
            > > that
            >
            > You knew it was the GIMP you were looking at. You expected it to be
            > good, and it was.
            >

            Probably. I judged it according to the interface it gave for scripting.
            Actually, I actively hacked on one part of it (the gradient editor) and it
            actually was faulty in not having a clear separation of the GUI from the
            gradient manipulation logic. And I wanted to create a gradient scripting
            layer (and eventually was able to).

            That does not mean it was bad, just that some important feaure escaped its
            author. This is natural, considering your first releases can always be
            improved upon.

            > > he prepared for our "Structure of OS" course, and could tell it was
            > > awful.
            >
            > You expected it to be awful, and therefore it was. It's a self
            > fullfilling prophecy.
            >

            Actually I expected it to be relatively good and was heavily disappointed.
            The code itself was legible, but very badly written and designed.

            > On a related tangent, big open source projects *have* to be written
            > well, since the code is one of the only line of communication between
            > the developers. If the code was not well written, the project would
            > either wither and die, or get rewritten.

            <sarcasm>There can be no metric to measure how well should a code be
            written</sarcasm> (;-)).

            Taking on on what Chen said, I can say that I had also an experience in
            which I slightly changed my opinion about a piece of code. The code in
            question was MikMod, which was an ANSI C MOD player that I converted to
            Java thru several stages of C++. At first I believed it was well-written.
            Later on, I discovered that it had a lot of limitations, but then again,
            maybe it was my fault for believing that I could convert it well by
            converting every C file into a class.

            MikMod became open-source a few years ago, and is still the most popular
            library for playing MOD files on UNIXes. I stopped maintaining the Java
            version, but it was operational and stable when I finished working on it.
            Someone should adapt it to JDK 1.4.x, but like I said, the code is
            extremely non-Javaish.

            Regards,

            Shlomi Fish

            > --
            > The ill-formed Orange
            > Fails to satisfy the eye: http://vipe.technion.ac.il/~mulix/
            > Segmentation fault. http://syscalltrack.sf.net/
            >
            >
            > To unsubscribe from this group, send an email to:
            > hackers-il-unsubscribe@egroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >
            >



            ----------------------------------------------------------------------
            Shlomi Fish shlomif@...
            Home Page: http://t2.technion.ac.il/~shlomif/
            Home E-mail: shlomif@...

            "Let's suppose you have a table with 2^n cups..."
            "Wait a second - is n a natural number?"
          • Shlomi Fish
            ... I have felt similarily when working on Freecell Solver. Of course, part of the reason, is that I keep thinking of new features to add, and then see that
            Message 5 of 6 , May 11, 2002
            • 0 Attachment
              On Sat, 11 May 2002, Chen Shapira wrote:

              >
              > > I'm definetely against "feeling" rather than knowing and reasoning
              > > assertions. But I suppose some experts can have first
              > > impressions that can
              > > eventually be reasoned, and usually found to be correct.
              >
              > The one consistency I found is that any piece of code *I* write, will look
              > like junk to me in a month.
              > Its natural, I learn a lot in a month...
              >

              I have felt similarily when working on Freecell Solver. Of course, part of
              the reason, is that I keep thinking of new features to add, and then see
              that the code cannot accumudate them well. So, I refactor it a bit and
              make it more modular, while adding new features in the process. (albeit
              I heard that refacoring is defined as changing the internals without
              changing the behaviour) And then, I'm relatively happy from it, until I
              think of new features.

              Of course one can argue that the "Hello World" program should be much more
              modular. Check:

              http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html

              for a funny spoof of this fact.

              > The only exception is a report generation system, which I wrote half a year
              > ago. I've been maintaining this system for 6 month now, and I'm still
              > suprised that I wrote something that grows so well.
              > After 3 years of writing report generators, I've managed to strike that
              > delicate balace between generality and simplicity.
              >

              Surprisingly enough, throughout all the time I maintained Freecell Solver,
              I did not have the need to re-write it from scratch. The code now is very
              different than version 0.2.0, and much larger in scope. But some code was
              kept very much the same from the beginning. (with the standard changes of
              changing myvar into instance->myvar, and other stuff like that).

              Throwing out your entire codebase, just because you have to do a major
              re-work is usually a bad idea, IMO. (and naturally, Joel Spolsky's) It's
              workink, so you'd better start from it, than from a clean gvim buffer.

              > I found that I'm a very bad judge of other people's code. I can't tell
              > anything at all at a quick glance.
              > Time after time my first impressions are changed after a week of
              > maintainance.
              > What looks like a mess at first glance, turns out to be an elegant solution
              > to a difficult problem. What looks elegant and impressive, turns out to be
              > unmaintainable spagetti of objects and templates.
              >

              Hmmppf. You are write that I rarely had the need to maintain other
              people's code. I did it several times for commercial software, and several
              time for open-source one, but usually I'm starting from something I
              originally wrote on my own. The problem is that many times I like to see
              if my software design theories will work, and I write a piece of code to
              test it. And sometimes it grows into a monstrosity that can do so much
              besides that.

              > IMO the most important things in a program are the functions and objects.
              > A function should do one thing well, diffrent functions should work together
              > without depending on inner implementation details.

              Right. And an important thing are the side-effects. I do not advocate
              writing programs in pure functional style, but each function should do
              what it is supposed to do, and have well-defined and rationalized
              side-effects. Otherwise, everything can become very messy.

              Of course, this is easier said than done.

              > An object should define a clear area of responsibility, control it well, and
              > stay away from the responsibilities of other objects.

              I sometimes like to have a bi-pole of two objects that each has a
              reference to the other, rather than inheriting them. Multiple-inheritance
              should not be abused.

              > All those things are extremely important, and rarely are they revealed in
              > one glance (or ten).
              >

              Perhaps you are right. There is a problem that it is a good idea to write
              a software incrementally rather than one big, integrated code that does
              too many things. And then in the next revisions, you realize things that
              you did not take into account. But I guess that would be the case, until
              someone writes good programs that will be able to generate code
              automatically based on some algorithm templates.

              In Star Trek TNG and friends, programming seems to be such a non-issue.
              In one episode of "Deep Space Nine", O'Brian generates an entire sub-system in
              one day, and one that is "more interesting" for an intelligent computer
              program, than the normal computer system of the station. Either he is a
              supreme programmer, or he could hack something very quickly using existing
              tools. Maybe he just installed a Linux distribution on a virtual machine
              there and made sure the computer program started to study it and hack
              on it... ;-)

              But the most important question still remains: who is John Galt?

              Regards,

              Shlomi Fish

              >
              >
              > To unsubscribe from this group, send an email to:
              > hackers-il-unsubscribe@egroups.com
              >
              >
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >



              ----------------------------------------------------------------------
              Shlomi Fish shlomif@...
              Home Page: http://t2.technion.ac.il/~shlomif/
              Home E-mail: shlomif@...

              "Let's suppose you have a table with 2^n cups..."
              "Wait a second - is n a natural number?"
            • Oleg Goldshmidt
              ... An experienced programmer can probably estimate whether or not he/she will be able to understand what is going on *and* whether he/she will be able to
              Message 6 of 6 , May 11, 2002
              • 0 Attachment
                Shlomi Fish <shlomif@...> writes:

                > But I'm not sure if feeling how good it is, can be explained in some
                > way.

                An experienced programmer can probably estimate whether or not he/she
                will be able to understand what is going on *and* whether he/she will
                be able to maintain it if needed *before* acrually understanding what
                is going on. Attention probably latches on familiar patters, snippets
                of logic, well thought through identifiers, usage of various
                abstraction and modularization techniques (e.g. ADTs), etc.

                I suspect the basic feature is readability, including things like
                consistent indentation, judicious use of whitespace and comments, and
                on top of that come easily recognizable techniques that are perceived
                as useful and beneficial.

                It is probably easier to determine that code is bad. If it is not
                intelligible at first sight, it likely is. ;-)

                > I can give various examples. For example, I cannot understand most of the
                > code of the Linux kernel,

                You probably can, just not on the first reading. You (and me) need to
                invest significant effort. It is rumoured that Linus doesn't need
                to...

                > but I know it is well-written, just by looking at it.

                It is possible that you *know* it is well written. IMH(umble)O, there
                are pieces that are not written well at all. It is probably individual
                to a large extent.

                --
                Oleg Goldshmidt | ogoldshmidt@...
                If it aint't broken it hasn't got enough features yet.
              Your message has been successfully submitted and would be delivered to recipients shortly.