Professional Web Applications Themes

coding standards question and RFC - PERL Beginners

On Apr 19, 2004, at 9:06 AM, Michael C. Davis wrote: [..]  [..] Props for the write up! You have clearly done your homework, and a reasonable arrangement of the basic 'talking points' about a coding standard. The problem then becomes, and I can not tell from your email - if you are in the position to be setting 'corporate policy' - Which is the Real Issue here. My own personal standard is that I follow, religiously, all of the rules in the perl style guidelines as best as I can. My corporate policy position is that I defer to ...

  1. #1

    Default Re: coding standards question and RFC


    On Apr 19, 2004, at 9:06 AM, Michael C. Davis wrote:
    [..] 
    [..]

    Props for the write up!

    You have clearly done your homework, and a reasonable
    arrangement of the basic 'talking points' about a
    coding standard.

    The problem then becomes, and I can not tell from
    your email - if you are in the position to be setting
    'corporate policy' - Which is the Real Issue here.

    My own personal standard is that I follow, religiously,
    all of the rules in the perl style guidelines as best
    as I can. My corporate policy position is that I defer
    to the 'chief perl perkin in residence' and leave it
    in their custody that they have agreed on such conventions.
    At that level it is more important to me that they agree
    on what their API signatures will be, how the overall
    design of their coding solution is, and that they can
    deliver on time.

    To be honest, I have delivered product where the naming
    convention also included 'inside jokes' that the code
    monkies thought were funny, did not distract from the
    overall project, and kept the code monkies coding happily.

    The ultimate concern is when the code is 'in maintenance'
    and someone else has to come along and maintain it. If
    the 'style guide' simplifies that process - it is a bonus.

    But you will probably find that spending time on creating
    the appropriate code coverage in the t/ and making sure
    that the POD is useful are the places where your time is best spent.

    ciao
    drieux

    ---

    Drieux Guest

  2. #2

    Default Re: coding standards question and RFC

    At 06:23 PM 4/19/04 -0700, drieux wrote: 

    Thanks for the insights, drieux. While I wish I were in a position to
    establish corporate policy, I'm not, and my objective is merely to satisfy
    myself that I have a reasoned, workable approach. Your feedback helps a lot.



    Michael Guest

  3. #3

    Default Re: coding standards question and RFC


    On Apr 21, 2004, at 4:16 AM, Michael C. Davis wrote:
    [..] 

    Coming up with a 'coding standard' in any language
    can be the first step on the road into the abyss.
    If it really helps with creating Clean API's then
    it is a good thing. If it becomes an excuse to
    merely 'refactor code' so that all of the curly
    braces are in compliance with a standard - rent a life,
    buying one may be too expensive at this point.

    But since one has started to see the merit of
    having a 'stock way' of seeing easily and quickly
    that some 'token' should be a [ constant | local_var | global_var |
    method | Module | briefPsychoticInterlude ] then
    it will make cutting the API's simpler - as everyone
    will use the same 'reading skills'.

    At which point one, in Perl, has already figured
    out that managing their Perl Modules is the simplest
    and cheapest way to 're-use code'.

    At which point it really is time to work on the
    whole t/ Test::Harness way of doenting and
    validating that the Module is Good. And that
    the POD is truthful and honest.

    I was explaining the transition from using Perl's
    t/ strategy and porting it over to doing c-code
    and that saved us a bunch when we did the 32-bit to
    64-bit cut over - because the obvious dumbs, and
    with them the core dumping in that t/ stopped when
    we had cleaned up the places where we wanted a u32int
    vice a 64-bit int... At which point we were ready to
    step forward and do the basic dynamic testing, and
    all was good with the world. When I chatted about
    this with the Freak who converted me to Perl, he
    noted:

    "oh no, I am a bit harsher. If the code does not
    come with a 'make test' - then I want your pager
    number, and you will be in my office within 15 minutes
    and YOU will be bringing the Chocolates..."

    Where this whole 't/' static testing saves one in the
    long run is that it will allow one to grow out the suite
    of basic tests over time as one has those ParaNoidDelusional
    moments that says:

    "but what if a code monkey did foo???"

    and if one builds the test, and it breaks your Module,
    then you needed to fix that anyway - and the test is
    still there in the t/ and the code is better...

    So in classical Trinitarianism it is:

    Phase I: Master Yourself

    Phase II: Collect Underlings

    Phase III: Global Domination!!!

    ciao
    drieux

    ---

    Drieux Guest

  4. #4

    Default Re: coding standards question and RFC

    drieux wrote:
     

    Stay independent.
     

    Kill all the robots.
     

    Enjoy peace.


    :)
    Wc Guest

Similar Threads

  1. Coding standards & Guidelines
    By Nayan Kawa in forum Macromedia Flex General Discussion
    Replies: 1
    Last Post: April 15th, 12:20 PM
  2. Coding Standards & Code Reviews?
    By evanb in forum Coldfusion - Advanced Techniques
    Replies: 3
    Last Post: April 7th, 06:35 PM
  3. Question coding a database app for Mac OSX
    By Kipp Chambers in forum Mac Programming
    Replies: 14
    Last Post: August 21st, 03:45 PM
  4. Coding Question
    By Aaron Axelsen in forum PHP Development
    Replies: 1
    Last Post: July 20th, 12:51 PM
  5. coding standards
    By shbgupta in forum ASP.NET General
    Replies: 2
    Last Post: June 27th, 08:48 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139