<p>I'm currently implementing a set of functions for data encoding and decoding. To avoid the list of if err != nil when encoding I used the code design pattern where the state is store in a struct containing a field holding the error. So we only need to test the error once at the end of all encoding calls. This provides indeed a huge code simplification and gain in readability. </p>
<p>But now the code implementing the encoding function became a little more verbose. I have currently two options and would like to know which one you find more readable and if there could be a better style which we could consider idiomatic.
This is style A</p>
<pre><code> type DecodeState struct {
data []byte
err error
}
func (d *DecodeState) Uint64() uint64 {
if d.err == nil {
dataLen := len(d.data)
if dataLen < 1 {
d.err = errors.New(...)
} else {
tag := d.data[0]
if tag != smallIntTag {
...
return val
} else if ... {
...
return val
} else {
d.err = errors.New(...)
}
}
}
return 0
}
</code></pre>
<p>In reality there is a third conditional level down.</p>
<p>This is style B</p>
<pre><code> func (d *DecodeState) Uint64() uint64 {
if d.err!= nil {
d.err = errors.New(...)
return 0
}
dataLen := len(d.data)
if dataLen < 1 {
d.err = errors.New(...)
return 0
}
tag := d.data[0]
if tag != smallIntTag {
...
return val
}
if ... {
...
return val
}
d.err = errors.New(...)
return 0
}
</code></pre>
<p>This second form reduces all conditional code to one level depth. Which is more readable ? Is there another more concise and readable style ?</p>
<hr/>**评论：**<br/><br/>SYS9000: <pre><p>Style B is more readable.</p></pre>danredux: <pre><p>Returning out of functions early is always preferable to having the rest of the function be inside an else block. I agree.</p></pre>nstratos: <pre><p>Style B is more idiomatic according to <a href="https://golang.org/doc/effective_go.html#if">effective Go</a>. I think it should generally be more readable by the majority as it has less conditional levels and less states to keep in mind while reading it. Style B also makes it possible to read it from top to bottom in one go.</p>
<p>I am also really happy to see someone actually doing some <a href="https://blog.golang.org/errors-are-values">programming with errors</a> instead of creating yet another thread to complain about them. Kudos to you sir.</p></pre>user3961: <pre><p>Be is better for both readability and less processing because of early returns. </p></pre>epiris: <pre><p>Hey I recently faced the same problem area as you. I opted for the B style if you want to see what a finished example may look like here is one, might give other ideas for ya too: <a href="https://github.com/cstockton/go-trace/blob/master/encoding/decoder.go" rel="nofollow">https://github.com/cstockton/go-trace/blob/master/encoding/decoder.go</a></p></pre>RalphCorderoy: <pre><p>B easily wins. You could try altering A to fix the needless <code>else</code> after a block that ends with <code>return</code> and you should see it moved more towards B. Not only needless, but confusing to the reader since you seem to be in two minds: return and yet continue, needing an <code>else</code>. Is one an error, they wonder.</p></pre>
