http://qs321.pair.com?node_id=11130647


in reply to [RFC] Review of module code and POD

It looks reasonable enough. Some possible improvements:
  1. Use a configuration file e.g. to store your environment setting as well as database credentials (decouple settings from code)
  2. Use DBIx::Class - you'll get search/insert and more functionality (almost) for free.
  3. Consider named parameters for methods with more than two args (makes code more self documenting).
  • Comment on Re: [RFC] Review of module code and POD

Replies are listed 'Best First'.
Re^2: [RFC] Review of module code and POD
by Bod (Parson) on Mar 31, 2021 at 23:09 UTC
    Use a configuration file

    Sorry if I'm being a bit thick but isn't that what I'm doing with use Bod::Variables; because all that's in there is a package statement and a list of scalars defined with our.

    Thanks for the suggestions.

      You're still keeping sensitive information in your code base, so that's not a configuration file.

      In the real world they are typically managed separately from the code base and often by people who may not be programmers (I realise your use case is simpler than the typical one).

      See Config::Tiny for an example.
        You're still keeping sensitive information in your code base, so that's not a configuration file

        Ah yes...I see the difference...

        However, I don't see what practical difference it makes assuming there is no encoding going on. If the code has access to the file that holds the sensitive information then surely the developer has access to the contents of that file either directly or through their code. I feel I am missing something here.

        In the 'real' code for the module, the only things that are pulled out of the module code are the database schema name, username and password. I only took table names out to share it in a public place for security purposes. Currently these are contained in a Perl module that does nothing but hold this kind of information and it would be good if I could amend this to a 'better', more secure arrangement especially as I am refactoring one of the sites that needs this information and now would be the perfect opportunity to do it.