emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [Proposal] Source Blocks with Post-Extensions


From: Tim Cross
Subject: Re: [O] [Proposal] Source Blocks with Post-Extensions
Date: Tue, 23 Apr 2019 06:59:50 +1000
User-agent: mu4e 1.1.0; emacs 26.2

YMMV, but personally, I think the real problem here is combining your
tests with your definition. i.e. square = lambda x: x * x is your real
code block while the return line is really just part of
testing/debugging and should not be in your definition block.

Tests are very important, but I find they 'clutter' the code and make it
harder to read/think about the core functionality - especially after
leaving and returning some time later to worik on the core code.

My approach is to keep the code blocks as 'pure' as possible and put all
the tests in a separate section of the org file. It does make code test
coverage a bit more challenging because you don't have the two 'side by
side', but I find that is offset by the increased clarity with the main
code.

just an alternative view ....

Dmitrii Korobeinikov <address@hidden> writes:

> For your convenience, I have attached this e-mail as an org-mode file.
>
> When I write several source blocks, which depend on one another, I tend to
> debug them one by one.
>
> So, I write this function and test it:
>
> #+NAME: square
> #+BEGIN_SRC python
>     square = lambda x: x * x
>     return square(5)
> #+END_SRC
>
> #+RESULTS: square
> : 25
>
> After I see that the test is successful, I write this client function:
>
> #+BEGIN_SRC python :noweb yes
>     <<square>>
>     return 5 + square(5)
> #+END_SRC
>
> #+RESULTS:
> : 25
>
> And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<<square>>~.
> But I don't want to lose testing!
> So I find nothing better to do than to seperate the source block:
>
> #+NAME: square-1
> #+BEGIN_SRC python
>     square = lambda x: x * x
> #+END_SRC
>
> And, by the way, there was no error/warning that I have just redefined
> ~<<square>>~,
> so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
> I think the org-mode team is aware of it, but anyway:
>
> - [ ] no error checking of the description of a code block.
>
> #+NAME: square-1-tester
> #+BEGIN_SRC python :noweb yes
>   <<square-1>>
>   return square(5)
> #+END_SRC
>
> #+RESULTS: square-1-tester
> : 25
>
> - [ ] For every such source block used for testing purposes, you have to
> repeat the inclusion statement and part of the name, which is cumbersome.
>
> A fair solution is maybe to extend the block like this:
>
> #+NAME: square-1
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC_TEST
>
> When I call this individually, the test part would run, but when I :noweb
> it in another block, the test part would be ommited.
>
> As an extension of this idea, it could be useful to have several test
> attachments like this, each producing its own result. Maybe, the TEST part
> could as well be ommited. Custom names are also an option:
>
> #+NAME: square-multiple
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC NAME: ext_1
>   return square(10)
> #+END_SRC NAME: ext_2
>
> #+RESULTS: square-multiple-ext-1
> : 25
>
> #+RESULTS: square-multiple-ext-2
> : 100
>
> Overall, these techniques should reduce noise and increase usability.


-- 
Tim Cross



reply via email to

[Prev in Thread] Current Thread [Next in Thread]