Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: Coding style: truth of variable name (subroutine length)

by Anonymous Monk
on Apr 19, 2020 at 02:54 UTC ( [id://11115767] : note . print w/replies, xml ) Need Help??


in reply to Coding style: truth of variable name

How long is your subroutines?

Variable names are much less important than subroutine names

file folder

for my $file ... grep glob whatever for my $path ... grep glob whatever for my $anal ... grep glob whatever

Replies are listed 'Best First'.
Re^2: Coding style: truth of variable name (subroutine length)
by perlancar (Hermit) on Apr 19, 2020 at 07:27 UTC

    My subroutines can range from just a few lines to over several hundred lines long. Labelled blocks sometimes help in making long subroutine clearer, as well as creating lexical scope to isolate the effect of variables.

    sub do_some_task { my ($arg1, $arg2, $arg3) = @_; SUBTASK1: { my $some_var = ... ... ... ... } ... SUBTASK2: { ... ... ... ... ... ... } ... ... }

    I do have to question your claim. What makes variable names much less important than subroutine names? Variables are referred to much more often.

      My subroutines can range from just a few lines to over several hundred lines long. I do have to question your claim. What makes variable names much less important than subroutine names? Variables are referred to much more often.

      isnt it obvious? subroutine length, obviously :)

      these are all identical for a screen full (40 to 100 lines) dir dir0 entry arg module modulepm file path ana

      entry arg anal dir0 are the shit versions from least to most. But only cause I dont actually think that way.

      Even they doesnt increase cognitive load... Var names only need to be close enough.

      hundred lines long ... arg1 arg2 arg3 subtask1 subtask2

      never

      chop it down to skimmable code

      @args Ebony() Ivory() Harmony()

      age of peter, sum of bob