Folks,
First off thanks for the feedback! -- positive and negative.
Second, hopefully people can trust that I fully understand the standard
approach to code refactoring and writing tests. I have done a bunch of it,
and am sure will continue to do a bunch of it. I understand the merits of
it. It is a valuable thing to do for the long run. No pejorative is
intended here.
That said, I am trying to reset here with another example about a possible
new way to have good tests AND have code for which it is easy to quickly
understand the relationships between all sub-tasks of the code -- it is
modified code from *The Go Programming Language* book. Note: There is a
bunch of "goto nonsense" added to get the Go compiler to accept the 4
labels for compiling.
The attributes that I would like to highlight are:
1. a *single* function which accomplishes a complete task
2. which is composed of *ordered* steps
3. where some steps may have *sub-steps*, and perhaps sub-sub-steps
Observations:
1. You can put this code into a modern editor with block expansion and
contraction, and contract the 3 main steps to easily show (without
scrolling) steps 1 to 3.
2. You can then expand step2 alone and see how step2A is clearly a
sub-step of step2.
3. You can also imagine how other sub-steps and sub-sub-steps would
maintain a *quasi-flow chart relationship* to each other -- top to
bottom, with indentation, etc.
4. You can also imagine that each step and sub-step could be a proper
func if refactored out of the parent func.
Aspirations:
1. Go language could be extended in some way that tests could be added
to steps WITHOUT refactoring the steps or sub-steps.
2. Adding such tests could accomplish the same effects as refactored
code, but WITHOUT losing the quasi-flow chart relationship of the steps.
3. Adding such tests could be faster to write by avoiding the
refactoring effort.
4. Adding tests this way could potentially produce faster running code
by avoiding the extra calls required by refactored code.
5. There is some possibility that a language extension could highlight
or define the specific variables that are most important to comprehend
while reading thru the code.
6. There is some possibility that a language extension could allow vars
(such as 'err') to be redefined per step, rather than the sometimes
problematic "fall-thru" definition of vars in prior code.
Critiques welcome,
Warren
package main
import (
"fmt"
"sync"
)
func main() {
fmt.Printf("Hello folks!\n")
err := doSomeStuff(true)
if err != nil {
fmt.Printf("doThisStuff did not succeed! %v\n", err)
}
fmt.Printf("Goodbye folks!\n")
}
const N = 20
var naturals = make(chan int, N)
var squares = make(chan int, N)
func doSomeStuff(dummy bool) error {
var n sync.WaitGroup
// there is a bunch of nonsense added here to get the Go compiler to accept
the 4 labels
// Counter
step1:
if dummy {
n.Add(1)
go func() {
for x := 0; x < N; x++ {
naturals <- x
}
n.Done()
}()
n.Wait()
if !dummy {
goto step1
}
}
// Squarer
step2:
if dummy {
n.Add(1)
go func() {
for x := 0; x < N; x++ {
v := <-naturals
squares <- v * v
// Squarer complainer
step2A:
if v > 1000000 {
fmt.Println("v is too big!")
v = 0
goto step2A
}
}
n.Done()
}()
n.Wait()
if !dummy {
goto step2
}
}
// Printer
step3:
if dummy {
n.Add(1)
go func() {
for x := 0; x < N; x++ {
n := <-squares
fmt.Println(x, n)
}
n.Done()
}()
n.Wait()
if !dummy {
goto step3
}
}
return nil
}
Again, it will be easier to understand the idea if the code is copied into
an editor with a block expansion and contraction feature.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/6e65e609-17cf-44cd-bb41-f6bd99969284%40googlegroups.com.
