in reply to Re: poll ideas quest 2019
in thread poll ideas quest 2019

Some people try to keep their use ...; declarations alphabetically sorted, saying that might help merges when multiple people add different uses... If one was to follow that route, use strict; would come before use warnings;.

Replies are listed 'Best First'.
Re^3: poll ideas quest 2019
by Tux (Abbot) on Nov 07, 2019 at 07:17 UTC

    I quite often sort them on length. Just a silly example:

    use 5.18.2; use warnings; use Carp; use DB_File; use DateTime; use Data::Peek; use File::Glob; use XML::Simple; use Time::HiRes; use Text::CSV_XS; use Sys::Hostname; use Tie::Hash::DBD; use File::Basename; use Module::Refresh; use Module::CoreList; use HTML::TreeBuilder; use DateTime::TimeZone; use Proc::ProcessTable; use Encode qw(encode decode);

    Enjoy, Have FUN! H.Merijn
Re^3: poll ideas quest 2019
by Eily (Monsignor) on Nov 07, 2019 at 00:10 UTC

    Ah yes, having so many use statements in a single file that you have to sort them to make them manageable, that happens all the time :'(. And having to add a bunch of modules in one go is common enough that two people do it in parallel on a daily basis. So annoying :/

      You do not need to add several to run into problems if you do not have an agreed upon place to add them.

      Are you going to add the single new one at the end? Alphabetically? Under a related module?

      1984 was supposed to be a warning,
      not a manual!

        Even if you add it in a random place I don't think adding a single line in a section of ~10 lines (in most cases) makes merging difficult. You might end up with a duplicate if two coders add the same module in two different places. But since auto-merging can lead to other issues*, the proper thing to do is to review the merged code anyway.

        *Possible problems with auto-merging a list of modules include:

        • Two modules that export two functions with the same name
        • The same module included but two coders, but one of them then changing one its options
        • Two different modules included, where one is just a wrapper for the second
        • ...

        I'm not saying that choosing an order for the use statements is a bad idea, though I mostly think it's a question of taste of prettiness of the code (which are important). I'm saying that if your stated reason is to make the list of includes more manageable, either there's something very wrong with your includes, or you have failed to consider solutions that solve more problems.