Tagged: go Toggle Comment Threads | Keyboard Shortcuts

  • ThomasPowell 9:39 pm on July 20, 2022 Permalink | Reply
    Tags: go, , nil   

    Golang nil returns suck ლ(ಠ益ಠლ) 

    Why might you return nil

    In many languages, if you want to represent “nothing” is returned, a common pattern is to use nil as a return value. A common alternative to this is the NullObjectPattern, since a 0/nil/null value generally does not respond to the same number of messages as a legitimate object value. This far more sparse interface is why languages like Ruby have introduced a Safe Navigation Operator. In languages that expose memory directly or indirectly like C++, trying to call object methods on a pointer to NULL could cause mangling of memory offset from that “zero” address.

    What happens in Golang with a nil return

    golang assertions against nil for multiple different representations
    Fighting through trying to match a golang nil return value (GitHub code link)

    If you have a reference or pointer return type, you can specify nil as a return value from it:

    type foo struct {
    }
    
    func fooMeOncePointerWithNil() *foo {
    	return nil
    }
    

    So if you’re writing a test for this (trivial) function, you might be tempted to write

    func TestFooMeOncePointerToArrayWithNil(t *testing.T) {
    	assert.Equal(t, nil, fooMeOncePointerToArrayWithNil(), "Test did not return nil")
    }
    

    But your assertion will fail, because the return value is *not* nil:

    ❯ go test
    --- FAIL: TestFooMeOncePointerToArrayWithNil (0.00s)
        main_test.go:23:
            	Error Trace:	/Users/tpowell/projects/golang/nilTest/main_test.go:23
            	Error:      	Not equal:
            	            	expected: <nil>(<nil>)
            	            	actual  : *[]testy.foo((*[]testy.foo)(nil))
            	Test:       	TestFooMeOncePointerToArrayWithNil
            	Messages:   	Test did not return nil
    FAIL
    exit status 1
    FAIL	testy	0.104s
    

    The actual type is nil cast to a *[]testy.foo cast to a *[]testy.foo.

    You can see this with returning to a pointer to an array of strings more clearly:

    func stringPointerToArrayNil() *[]string {
    	return nil
    }
    
    func TestStringNil(t *testing.T) {
    	assert.Equal(t, nil, stringPointerToArrayNil(), "Function did not return nil")
    }
    

    Which fails similarly, although slightly more readably:

    --- FAIL: TestStringNil (0.00s)
        main_test.go:42:
            	Error Trace:	/Users/tpowell/projects/golang/nilTest/main_test.go:42
            	Error:      	Not equal:
            	            	expected: <nil>(<nil>)
            	            	actual  : *[]string((*[]string)(nil))
            	Test:       	TestStringNil
            	Messages:   	Function did not return nil
    FAIL
    exit status 1
    FAIL	testy	0.246s

    What Technically Works?

    So how we make a nil return value match? Well, you can typecast nil explicitly to match the implicit casting of the returned nil:

    func TestPassFooMeOncePointerToArrayWithNil(t *testing.T) {
    	assert.Equal(t, (*[]foo)(nil), fooMeOncePointerToArrayWithNil(), "Test did not return nil")
    }
    

    Now you’ll get:

    ❯ go test
    PASS
    ok testy 0.141s

    A better “nil”?

    Having to contort a language to do a basic thing is usually an indicator you’re probably using it wrong. In this case, perhaps you just want an empty array:

    func fooMeOnceArray() []foo {
    	return []foo{}
    }
    

    Now you can validate this with the len function on the returned array:

    func TestFooMeOnceArray(t *testing.T) {
    	assert.Equal(t, 0, len(fooMeOnceArray()), "Test did not return nil")
    }
    

    This, of course, passes, but tested against the number of items returned instead of checking for an arbitrary nil value.

    Maybe you just want to check error

    Golang supports multiple return values, and you can add a return of an error type:

    func fooMeOnceArrayError() ([]foo, error) {
    	return []foo{}, nil
    }
    

    The error type *can* be cleanly compared to nil:

    func TestFooMeOnceArrayError(t *testing.T) {
    	_, error := fooMeOnceArrayError()
    	assert.Equal(t, nil, error, "Test did not return nil")
    }
    

    This comparison to nil passes:

    ❯ go test
    PASS
    ok testy 0.238s

    Conclusion

    The bigger lesson in all of this is that if the direction that you’re going down in a language feels unnatural, there might be a better way to do things. Or you might not even be using a pattern that is preferred for the language. Take a step back and look at the bigger picture.

     
  • ThomasPowell 12:08 pm on July 6, 2017 Permalink
    Tags: go, indentation, , spaces, tabs, whitespace   

    Whitespace is Significant 

    While I was in my first couple years of college, Python was gaining traction as a hot new programming language. I had been programming in C since high school, but was curious about new languages. I took an interest in learning more about Python. A classmate told me that whitespace (at least indentation) was significant in Python. I changed my mind.

    The Holy Wars of Indentation Style


    // From https://en.wikipedia.org/wiki/Indent_style
    // K & R
    while (x == y) {
    something();
    somethingelse();
    }
    // 1TBS
    if (x < 0) {
    puts("Negative");
    } else {
    nonnegative(x);
    }
    // Stroustup
    if (x < 0) {
    puts("Negative");
    negative(x);
    }
    else {
    puts("Non-negative");
    nonnegative(x);
    }
    // Allman
    while (x == y)
    {
    something();
    somethingelse();
    }
    // GNU
    while (x == y)
    {
    something();
    somethingelse();
    }
    // Whitesmiths
    while (x == y)
    {
    something();
    somethingelse();
    }
    // Horstmann
    while (x == y)
    { something();
    somethingelse();
    }
    // Pico
    while (x == y)
    { something();
    somethingelse(); }
    // Ratliff
    while (x == y) {
    something();
    somethingelse();
    }
    // LISP
    while (x == y) {
    something();
    somethingelse(); }

    view raw

    indent.c

    hosted with ❤ by GitHub

    It’s interesting that would’ve been so turned off by a language that placed significance on whitespace and indentation, when I had fantasized about holy wars revolving around C indentation style (Horstmann is the only way!) and tabs vs. spaces (tabs, tab width 4!). I wretched at anything in the GNU C coding style (okay, I still do…), but the funny thing was, I never was able to program in a consistent style: There were other co-workers who had a slightly different preferred style. I was also learning myself, so relative importance of information in code changed, and my opinions on bracing style evolved.

    Non-C Languages that Use Curly Braces for Things

    It was a combination of Java, JavaScript, Perl, and Ruby that altered my perception of “proper” bracing style (BUT NOT SPACES OVER TABS!). A new line after a conditional or function declaration/call before the brace either took up unnecessary amounts of space, or changed the meaning of the code altogether (e.g., blocks in ruby, for which adding a newline = syntax error). And so, I evolved into declaring that 1TBS style was the only proper way to write C (WITH TABS!)

    Ruby

    Ruby has a generally accepted coding style that is enforced by no one except for code reviewers and maybe draconian RuboCop build configurations. I’d link to the coding style, if I had any certainty that the one I grabbed was 99% correct. Even RubyMine doesn’t format code to the same standards as RuboCop.  (Continuation indent and spacing around braces were two settings I had to tweak.)

    Small inconsistencies aside, Ruby code has ended up being the most consistent—visually—to support and add code to. I’ve introduced tighter RuboCop configurations on newer projects to try to adhere more closely to generally accepted coding style for Ruby.

    Ruby also introduced me to an acceptance of significant whitespace. While C code often gets sloppy with spacing around punctuation markers in code, Ruby developers take more care in proper whitespace around the conditionals, braces, etc. Some C/C++ projects like Mozilla do similar standards. However, Ruby is the first language that I’ve seen a community-wide interest in code that presents in the same manner. Of course, most of this code isn’t syntactically significant, but it is of human significance–and humans have their own mental compilers that optimize on standard patterns.

    Still, this isn’t the largest impact Ruby has had on my opinion of significant whitespace. Through Ruby, I’ve been exposed to YAML, HAML, and Slim. (I have dibs on forming a band of Rubyists with that name!) All three languages are unforgiving about inconsistent indentation. They take out explicit expression of boundaries and create visually implicit boundaries via hierarchies of indents. You don’t need to look for an end or closing brace to know that the context has moved up a level. The indentation tells you where that happens.

    (And yes, because of the generally accepted coding style in Ruby, I use 2 spaces instead of tabs now.)

    Golang

    And yet, Ruby coding style is informal. You can code in improper style and still commit your code and/or run it. There’s something about having the freedom to write improper style and being able to be a good “citizen” on your own that is comforting.

    Go does not do this. Writing Go in any editor configured to code in it (I’ve been using the vim-go plugin) automatically formats via gofmt.  It’s pretty unsettling. I longed for the ability to become dictator over coding styles, and then was okay when Ruby dictated one, but gave us the autonomy to do the right thing. This auto-formatting? This is tyranny!

    But, perhaps, it’s time. We can mentally chunk pieces into larger concepts for storage, if code that does the same thing looks the code. Instead of having to remember every brace as an individual piece, we can put “for loop that iterates and prints” as a single chunk.

    A stray brace isn’t going to permanently prevent distillation into larger chunks; it will just take a higher cognitive load to get there. This in turn will require more experience with the language before a programmer can make that leap. Being able to break things into large chunks helps us discover the what instead of dwelling on the how.

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel
%d bloggers like this: