in reply to 20 most important Perl Best Practices

This node falls below the community's minimum standard of quality and will not be displayed.
  • Comment on Re: 20 most important Perl Best Practices

Replies are listed 'Best First'.
Re^2: 20 most important Perl Best Practices
by eyepopslikeamosquito (Archbishop) on May 02, 2024 at 22:52 UTC
[reply]
      Yes, of course. I think, I did use the word "compile" meaning that I did not write these rules, I copied them from "various sources" which I found on this page. So, these aren't entirely my own rules. Let's just say, I just "tweaked" some of them a little bit to fit my style. I also deleted a handful of them which I disagree with. lol ;)
[reply]

        I copied them from "various sources" which I found on this page. So, these aren't entirely my own rules.

        It'd be good if you listed your primary sources while identifying original coding rules that you invented ... I think it's safe to say you invented these two :-)

        • Don't do stupid things
        • Think about what you write

        I'd forgotten I'd already compiled Coding Standards References -- there's certainly no shortage of opinions and references on this topic. 

        👁️🍾👍🦟
[reply]
Re^2: 20 most important Perl Best Practices
by GrandFather (Saint) on May 03, 2024 at 04:36 UTC

    I tried compiling that with all the compilers I have access to and none of them compiled it, not even PL/I!

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]
Re^2: 20 most important Perl Best Practices
by stevieb (Canon) on May 03, 2024 at 19:33 UTC

    My personal feedback...

    Never place two statements on the same line unless they are somehow related or part of the same logic process. Always start your elsif or else block on a new line. unless the last elsif block contains a very short line and the next else {} block also contains a very short line. In that case, it's ok. For example: elsif ($Color & 255) { $RGB++; } else { $GRAY++; }

    Doing that breaks readibility flow.

    Use CamelCase whenever possible, for more important variables, use all uppercase letters.

    That breaks decades of the de-facto Perl standardized naming scheme of snake_case.

    Avoid using constants as much as possible. But if you must, use all caps and very short names for constants (4-5 letters).

    Use constants whenever they are deemed necessary, instead of global variables, and don't limit the name length. The variable name should be as long as needed so that it conveys what the variable's purpose is. Here are two examples:

    use constant {
 
    DEFAULT_QUEUE       => 0x03,  # bits 1-0 (0-3)
    MAX_QUEUE           => 0x03,
 
    DEFAULT_POLARITY    => 0x00,  # bit  3
    MAX_POLARITY        => 0x08,
 
    DEFAULT_RATE        => 0x00,  # bits 7-5
    MAX_RATE            => 0xE0,
 
    DEFAULT_MODE        => 0x100, # bit  8
    MAX_MODE            => 0x100,
 
    DEFAULT_GAIN        => 0x200, # bits 11-9
    MAX_GAIN            => 0xE00,
 
    DEFAULT_CHANNEL     => 0x4000, # bits 14-12
    MAX_CHANNEL         => 0x7000,
};

    [download]
    use constant {
    DEBUG_CACHE                 => $ENV{DEBUG_TESLA_API_CACHE},
    API_CACHE_PERSIST           => 0,
    API_CACHE_TIMEOUT_SECONDS   => 2,
    API_TIMEOUT_RETRIES         => 3,
    AUTH_CACHE_FILE             => "$home_dir/tesla_auth_cache.json",
    ENDPOINTS_FILE              => $ENV{TESLA_API_ENDPOINTS_FILE} // d
+ist_file('Tesla-API', 'endpoints.json'),
    OPTION_CODES_FILE           => $ENV{TESLA_API_OPTIONCODES_FILE} //
+ dist_file('Tesla-API', 'option_codes.json'),
    TOKEN_EXPIRY_WINDOW         => 5,
    URL_API                     => 'https://owner-api.teslamotors.com/
+',
    URL_ENDPOINTS               => 'https://raw.githubusercontent.com/
+tdorssers/TeslaPy/master/teslapy/endpoints.json',
    URL_OPTION_CODES            => 'https://raw.githubusercontent.com/
+tdorssers/TeslaPy/master/teslapy/option_codes.json',
    URL_AUTH                    => 'https://auth.tesla.com/oauth2/v3/a
+uthorize',
    URL_TOKEN                   => 'https://auth.tesla.com/oauth2/v3/t
+oken',
    USERAGENT_STRING            => 'Mozilla/5.0 (Macintosh; Intel Mac 
+OS X 10.15; rv:98.0) Gecko/20100101 Firefox/98.0',
    USERAGENT_TIMEOUT           => 180,
};

    [download]
    Always use warnings and strict. Adopt a policy of zero tolerance for warnings and errors.

    That should be rule number one. Rule number two (IMHO) should be write tests as you write code. Let the test code help you dictate the interface.

    Lines should not exceed 70 characters unless absolutely necessary.

    This is actually 80, because years ago that was the width of a terminal. This isn't really necessary any longer (but I do still for the vast majority of the time stick with it).

    I don't like to use TABS. I always use two spaces to indent code.

    Much more common is four-space tabs.

[reply]
[d/l]
[select]
Re^2: 20 most important Perl Best Practices
by GrandFather (Saint) on May 04, 2024 at 13:10 UTC

    My poor bleeding eyes!

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]

In Section Meditations