Good form

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Good form

Donald Steven
Sometimes, when a variable is bound then used only once in a function call, it seems easier just to just use what it is bound to directly in the function call, bypassing the first step.

Here's an example:

getSound(Event) -> element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag, Event))),
hd(lists:nth(maps:get(templateTag, Event), agitatedSoundResources(maps:get(scalarTag, Event), maps:get(registerTag,
Event), maps:get(transpositionTag, Event))))).

Alternatively, I could have declared, for example, a raft of variable like ElementNumber, ElementTag, TemplateTag, etc.

I realize that this all-in-one-compact version tends towards  inscrutabel c code liek &X++ ?.

How do you approach the temptation to avoid discrete steps in favor of compactness?

Thanks.

Don


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Good form

Hugo Mills-2
On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote:

> Sometimes, when a variable is bound then used only once in a
> function call, it seems easier just to just use what it is bound to
> directly in the function call, bypassing the first step.
>
> Here's an example:
>
> getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag,
> Event))),
> hd(lists:nth(maps:get(templateTag, Event),
> agitatedSoundResources(maps:get(scalarTag, Event),
> maps:get(registerTag,
> Event), maps:get(transpositionTag, Event))))).
>
> Alternatively, I could have declared, for example, a raft of
> variable like ElementNumber, ElementTag, TemplateTag, etc.
>
> I realize that this all-in-one-compact version tends towards
> inscrutabel c code liek &X++ ?.
>
> How do you approach the temptation to avoid discrete steps in favor
> of compactness?
   I don't find it tempting at all. :)

   The discrete steps can be useful documentation, because you can
give the interim variables meaningful names, explaining (a little)
what it is that you're doing.

   It also helps to break up the calls for formatting and readability,
particularly if you have functions with multiple parameters in the
sequence.

   Hugo.

--
Hugo Mills             | The most exciting phrase to hear in science, the one
hugo@... carfax.org.uk | that heralds new discoveries, is not "Eureka!", but
http://carfax.org.uk/  | "That's funny..."
PGP: E2AB1DE4          |                                          Isaac Asimov

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Good form

Richard O'Keefe
At one extreme we reach the 'point-free' style liked in Haskell,
or the 'pipeful' style common in F#.
There is a place for that sort of thing,
but I'm not convinced that code meant for other people
to read is that place.
Think of introducing variables as an opportunity to make
your code easier to understand, not as a cost.

On Fri, 15 Mar 2019 at 11:36, Hugo Mills <[hidden email]> wrote:
On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote:
> Sometimes, when a variable is bound then used only once in a
> function call, it seems easier just to just use what it is bound to
> directly in the function call, bypassing the first step.
>
> Here's an example:
>
> getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag,
> Event))),
> hd(lists:nth(maps:get(templateTag, Event),
> agitatedSoundResources(maps:get(scalarTag, Event),
> maps:get(registerTag,
> Event), maps:get(transpositionTag, Event))))).
>
> Alternatively, I could have declared, for example, a raft of
> variable like ElementNumber, ElementTag, TemplateTag, etc.
>
> I realize that this all-in-one-compact version tends towards
> inscrutabel c code liek &X++ ?.
>
> How do you approach the temptation to avoid discrete steps in favor
> of compactness?

   I don't find it tempting at all. :)

   The discrete steps can be useful documentation, because you can
give the interim variables meaningful names, explaining (a little)
what it is that you're doing.

   It also helps to break up the calls for formatting and readability,
particularly if you have functions with multiple parameters in the
sequence.

   Hugo.

--
Hugo Mills             | The most exciting phrase to hear in science, the one
hugo@... carfax.org.uk | that heralds new discoveries, is not "Eureka!", but
http://carfax.org.uk/  | "That's funny..."
PGP: E2AB1DE4          |                                          Isaac Asimov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJcitdGAAoJEFheFHXiqx3khsgP/2+gnwII70wb5JGoX4i+U78F
/aLbdSA7mtYDlXJDevPmwAr0unZZOG4A+EM8pytRXLmN1lxanOU5Ja1LIsDTWJFP
AsjwbAH2pVtdFerwug6braBFNyD+vyoPpYo3lni+UnmDmaeCTR88C9np5Nvi07bZ
TJRVoi5Sx7pRo5m4P2v2O2diTb/Gt8Xxk+zkvOzo5obSAsB8bzLhDiL/fVnCR91m
6Z4bk2eL/iVvuYqhVQmpIrMDGJvzzqW1POuevoE7+/HdScFzHv8Xow3XxDmPC3TT
r/04lviaZounef0mymNsVILmsQUzpF/ZMq3X8KLddbFovqRLbxyYmtgiMs8iyfvF
0tbKfM53Y+LbKvRdmVe50lDVR1C8KAPvpUO+piFh3lP5aOK9r8vK0v5R9v9exMwp
yNqspsNZk6iTnF4Mxaa2P80vHM2DmAfdiKYLZb9gqJKXbuC9g1t2g6z+1GP1Y9JS
HuUaTX3ed0zdzmNWT7YxaSsWi6TJp9lhTH4gcfqNLmvr4wgsgPABD1KqoOgverrZ
yJcwEKk2xuuZt5xLvNdJacN1VWZS/ybQiko022JR4iXV1nXoz/P8tR1rx+tKez2u
y3gqdrPVA4XT/X8j+YrkLm3G2v1XJy6+ANO2oe+Iz41vgi0EtbVywZZKyChUry6u
Qpsht+QWZofR+vdWzk4Q
=fKS8
-----END PGP SIGNATURE-----
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Good form

Robert Carbone
In reply to this post by Hugo Mills-2

I couldn't agree more with Hugo & Richard -

We are programming in a high level language here; you shouldn't be trying to compact your code unless you are trying to obfuscate it.

And as far as I understand it, the compiler is going to make those substitution optimizations for you


So absolutely, line up your variables nicely,  give them good names, keep things in short & make it readable.
Other peeps, & more probably your future-self, will thank you.

All this is great Erlang coding technique and solid habits to be forming.

- Rob C.
scriptculture.com



On 3/14/19 6:35 PM, Hugo Mills wrote:
On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote:
Sometimes, when a variable is bound then used only once in a
function call, it seems easier just to just use what it is bound to
directly in the function call, bypassing the first step.

Here's an example:

getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(<a class="moz-txt-link-freetext" href="maps:get(elementTag">maps:get(elementTag,
Event))),
hd(lists:nth(<a class="moz-txt-link-freetext" href="maps:get(templateTag">maps:get(templateTag, Event),
agitatedSoundResources(<a class="moz-txt-link-freetext" href="maps:get(scalarTag">maps:get(scalarTag, Event),
<a class="moz-txt-link-freetext" href="maps:get(registerTag">maps:get(registerTag,
Event), <a class="moz-txt-link-freetext" href="maps:get(transpositionTag">maps:get(transpositionTag, Event))))).

Alternatively, I could have declared, for example, a raft of
variable like ElementNumber, ElementTag, TemplateTag, etc.

I realize that this all-in-one-compact version tends towards
inscrutabel c code liek &X++ ?.

How do you approach the temptation to avoid discrete steps in favor
of compactness?
   I don't find it tempting at all. :)

   The discrete steps can be useful documentation, because you can
give the interim variables meaningful names, explaining (a little)
what it is that you're doing.

   It also helps to break up the calls for formatting and readability,
particularly if you have functions with multiple parameters in the
sequence.

   Hugo.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Good form

Donald Steven
Thanks everyone, much appreciated.

Don

On 3/15/2019 11.16 AM, Robert Carbone wrote:

I couldn't agree more with Hugo & Richard -

We are programming in a high level language here; you shouldn't be trying to compact your code unless you are trying to obfuscate it.

And as far as I understand it, the compiler is going to make those substitution optimizations for you


So absolutely, line up your variables nicely,  give them good names, keep things in short & make it readable.
Other peeps, & more probably your future-self, will thank you.

All this is great Erlang coding technique and solid habits to be forming.

- Rob C.
scriptculture.com



On 3/14/19 6:35 PM, Hugo Mills wrote:
On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote:
Sometimes, when a variable is bound then used only once in a
function call, it seems easier just to just use what it is bound to
directly in the function call, bypassing the first step.

Here's an example:

getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(<a class="moz-txt-link-freetext" href="maps:get(elementTag" moz-do-not-send="true">maps:get(elementTag,
Event))),
hd(lists:nth(<a class="moz-txt-link-freetext" href="maps:get(templateTag" moz-do-not-send="true">maps:get(templateTag, Event),
agitatedSoundResources(<a class="moz-txt-link-freetext" href="maps:get(scalarTag" moz-do-not-send="true">maps:get(scalarTag, Event),
<a class="moz-txt-link-freetext" href="maps:get(registerTag" moz-do-not-send="true">maps:get(registerTag,
Event), <a class="moz-txt-link-freetext" href="maps:get(transpositionTag" moz-do-not-send="true">maps:get(transpositionTag, Event))))).

Alternatively, I could have declared, for example, a raft of
variable like ElementNumber, ElementTag, TemplateTag, etc.

I realize that this all-in-one-compact version tends towards
inscrutabel c code liek &X++ ?.

How do you approach the temptation to avoid discrete steps in favor
of compactness?
   I don't find it tempting at all. :)

   The discrete steps can be useful documentation, because you can
give the interim variables meaningful names, explaining (a little)
what it is that you're doing.

   It also helps to break up the calls for formatting and readability,
particularly if you have functions with multiple parameters in the
sequence.

   Hugo.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions