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

Re: [hackers-il] Why there will always be programmers

Expand Messages
  • Shlomi Fish
    ... Well, I never initiated large-scale projects on my own, just contributed to large-scale ( 100K LOCs) projects that other people initiated. Well, first of
    Message 1 of 3 , Nov 3, 2008
    • 0 Attachment
      On Friday 31 October 2008, Omer Zak wrote:
      > http://www.johndcook.com/blog/2008/10/27/why-there-will-always-be-programme
      >rs/ Summary:
      > Programmers are always needed, because big programs have lots of
      > details, and somebody has to manage those details.
      >
      > Now, quick! What are your tips and tricks for managing the details of
      > your projects?

      Well, I never initiated large-scale projects on my own, just contributed to
      large-scale ( > 100K LOCs) projects that other people initiated.

      Well, first of all I make sure the projects are adequately modular and
      componentised. Each module, class, function etc. should do something and
      something well. This makes it easy to find.

      Meaningful and conventional variable names also help a lot to find offending
      code.

      Then I use tools like grep, http://petdance.com/ack/ , ctags, etc. to find
      what I want. These are especially useful with gvim's quickfix mode.

      I personally don't write too much external documentation, except for
      perlpod/etc. API-documentation for the user. I also prefer to factor out code
      with meaningful names for the extracted functions than to comment bad code.
      From my experience, external documentation tends to get out-of-sync with the
      code itself and so is not such a good idea. Your code should be
      self-documenting.

      Regards,

      Shlomi Fish

      -----------------------------------------------------------------
      Shlomi Fish http://www.shlomifish.org/
      What Makes Software Apps High Quality - http://xrl.us/bkeuk

      Shlomi, so what are you working on? Working on a new wiki about unit testing
      fortunes in freecell? -- Ran Eilam
    • Ori Idan
      ... I certainly agree that code should be self documenting as much as possible. Sometimes even in line documentation in the form of comments, tends to stay out
      Message 2 of 3 , Nov 3, 2008
      • 0 Attachment


        On Mon, Nov 3, 2008 at 9:05 PM, Shlomi Fish <shlomif@...> wrote:
        >rs/ Summary:
        > Programmers are always needed, because big programs have lots of
        > details, and somebody has to manage those details.
        >
        > Now, quick!  What are your tips and tricks for managing the details of
        > your projects?

        Well, I never initiated large-scale projects on my own, just contributed to
        large-scale ( > 100K LOCs) projects that other people initiated.

        Well, first of all I make sure the projects are adequately modular and
        componentised. Each module, class, function etc. should do something and
        something well. This makes it easy to find.

        Meaningful and conventional variable names also help a lot to find offending
        code.

        Then I use tools like grep, http://petdance.com/ack/ , ctags, etc. to find
        what I want. These are especially useful with gvim's quickfix mode.

        I personally don't write too much external documentation, except for
        perlpod/etc. API-documentation for the user. I also prefer to factor out code
        with meaningful names for the extracted functions than to comment bad code.
        From my experience, external documentation tends to get out-of-sync with the
        code itself and so is not such a good idea. Your code should be
        self-documenting.

        I certainly agree that code should be self documenting as much as possible.
        Sometimes even in line documentation in the form of comments, tends to stay out of date. I have seen case when during debugging of some software, some functions where changed but the comments stayed the same.

        --
        Ori Idan
          


        Regards,

               Shlomi Fish

        -----------------------------------------------------------------
        Shlomi Fish       http://www.shlomifish.org/
        What Makes Software Apps High Quality -  http://xrl.us/bkeuk

        Shlomi, so what are you working on? Working on a new wiki about unit testing
        fortunes in freecell? -- Ran Eilam

        ------------------------------------

        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
           http://groups.yahoo.com/group/hackers-il/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           http://groups.yahoo.com/group/hackers-il/join
           (Yahoo! ID required)

        <*> To change settings via email:
           mailto:hackers-il-digest@yahoogroups.com
           mailto:hackers-il-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
           hackers-il-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
           http://docs.yahoo.com/info/terms/




        --
        ספרים וסיפורים שכתבתי: http://www.thestories.org
      Your message has been successfully submitted and would be delivered to recipients shortly.