6 ms·

Go, robots and refactoring

98 points by mattetti 12y ago

wolfeidau 12y ago
Great post really enjoyed it. Also a big fan of golang, loving the posts by people using it in anger. Thanks
joefitzgerald 12y ago
This is a really helpful article - nice work Matt.
- mattetti 12y ago
  Thanks joe, I realized that the best way to learn is to refactor with one or more people. Hopefully, this summary of a quick refactoring will help others too.
enneff 12y ago
I would suggest naming the method "Device" instead of "GetDevice". The word "Get" is almost always redundant.
- mattetti 12y ago
  I totally agree, I found myself refactoring my own code and renaming "Get<>()" functions. I wish I had heard someone say that earlier :) m.FindRobot("bot name").GetDevice("laser") would read better as m.Robot("bot name").Device("laser")
  - zura 12y ago
    Agree, but due to my mild OCD, I still keep using Get to pair with Set :)
    - enneff 12y ago
      I also feel that mild nagging feeling, but it passes quickly. The brevity is worth it. :-)
    - davvid 12y ago
      Another reason I've heard for avoiding getFoo() is that on certain typefaces the lower-case "g" and "s" look similar enough that folks with bad vision can confuse them[1]. Thus foo() and setFoo() are clearer than getFoo() and setFoo(). [1] Given enough time in front of a monitor, we all get bad vision eventually ;-)
      - plorkyeran 12y ago
        That's easily solved by just not using typefaces that you can't read in your editor.
codegangsta 12y ago
Nice post Matt! I would love to see more of these eyewitness accounts of refactoring in the go community. Maybe a refactoring video should be in the works ;)
- mattetti 12y ago
  Thanks Jeremy, let's book a few hours and do that together.
2mur 12y ago
This is really helpful. I'm getting started with Go now and common idioms and refactoring are useful when moving past the tour and introduction stage.
wyager 12y ago
>Go aka golang is an amazing language By what standard? I've been very underwhelmed. The type system is very mediocre. Support for generic programming is awful. What kind of language idiomatically involves casting to the top type? That would be like if Java idiomatically involved casting to Object, or C++ idiomatically involved casting to void*, just to get any sort of genericism. Look at almost any big Go project; the abundance of {}interface typed variables is alarming And then how about language extensibility? Go relies heavily on built-in keywords, like range and make(). You want to range over a tree or a linked list? Too bad. You can only use built-in types. Or maybe you can wrap your data structure in a chan and range over that. Goodbye performance and simplicity. Go is not a bad language. I use it on a number of web projects, and it works very well. But Go is not, by any metric I can think of, an "amazing" language. At best, it is a decent language with lots of corporate support, a good standard library, and some good tools like golint, go get, and go fmt.
- kyrra 12y ago
  I'd agree that Go's language syntax and symantics are very simple at this point. I'm really hoping they improve some of these simple use cases with Go2 whenever that comes about. What I really like is the whole toolchain that comes with it. Fast compile times, cross-compiling, static binaries for easy deployment, gofmt, godoc, gocode, etc.
  - pjmlp 12y ago
    > What I really like is the whole toolchain that comes with it. Fast compile times, cross-compiling, static binaries for easy deployment, gofmt, godoc, gocode, etc. If it also had an OS coded in it, it would be called Oberon (1992).
    - 0xdeadbeefbabe 12y ago
      The name Oberon would be easier to google too. An alarming number of false positives taught me to search for "golang" instead. A small baseline level of alarm is good when you are programming in go for obvious reasons, including {}interface etc.
djb_hackernews 12y ago
Go looks interesting. Anyone else not a fan of the single character variable names? Also, Is there a better way, in terms of clarity, to do this: <- c Even with the comment I would think the developer forgot to fill in the first half of that and assume it was a bug.
- mattetti 12y ago
  In the first version of the post I had _ = <- c To show that we don't use the value read from the channel, but someone in my team pointed that, that this isn't very idiomatic and mainly a way to explain what the code does to someone who doesn't know Go.
solojavier 12y ago
Thanks for sharing this Matt.. really good insight.

98 points by mattetti 12y ago

wolfeidau 12y ago

Great post really enjoyed it. Also a big fan of golang, loving the posts by people using it in anger. Thanks

joefitzgerald 12y ago

This is a really helpful article - nice work Matt.

mattetti 12y ago
Thanks joe, I realized that the best way to learn is to refactor with one or more people. Hopefully, this summary of a quick refactoring will help others too.

enneff 12y ago

I would suggest naming the method "Device" instead of "GetDevice". The word "Get" is almost always redundant.

mattetti 12y ago
I totally agree, I found myself refactoring my own code and renaming "Get<>()" functions. I wish I had heard someone say that earlier :) m.FindRobot("bot name").GetDevice("laser") would read better as m.Robot("bot name").Device("laser")
- zura 12y ago
  Agree, but due to my mild OCD, I still keep using Get to pair with Set :)
  - enneff 12y ago
    I also feel that mild nagging feeling, but it passes quickly. The brevity is worth it. :-)
  - davvid 12y ago
    Another reason I've heard for avoiding getFoo() is that on certain typefaces the lower-case "g" and "s" look similar enough that folks with bad vision can confuse them[1]. Thus foo() and setFoo() are clearer than getFoo() and setFoo(). [1] Given enough time in front of a monitor, we all get bad vision eventually ;-)
    - plorkyeran 12y ago
      That's easily solved by just not using typefaces that you can't read in your editor.

codegangsta 12y ago

Nice post Matt! I would love to see more of these eyewitness accounts of refactoring in the go community. Maybe a refactoring video should be in the works ;)

mattetti 12y ago
Thanks Jeremy, let's book a few hours and do that together.

2mur 12y ago

This is really helpful. I'm getting started with Go now and common idioms and refactoring are useful when moving past the tour and introduction stage.

wyager 12y ago

>Go aka golang is an amazing language By what standard? I've been very underwhelmed. The type system is very mediocre. Support for generic programming is awful. What kind of language idiomatically involves casting to the top type? That would be like if Java idiomatically involved casting to Object, or C++ idiomatically involved casting to void*, just to get any sort of genericism. Look at almost any big Go project; the abundance of {}interface typed variables is alarming And then how about language extensibility? Go relies heavily on built-in keywords, like range and make(). You want to range over a tree or a linked list? Too bad. You can only use built-in types. Or maybe you can wrap your data structure in a chan and range over that. Goodbye performance and simplicity. Go is not a bad language. I use it on a number of web projects, and it works very well. But Go is not, by any metric I can think of, an "amazing" language. At best, it is a decent language with lots of corporate support, a good standard library, and some good tools like golint, go get, and go fmt.

kyrra 12y ago
I'd agree that Go's language syntax and symantics are very simple at this point. I'm really hoping they improve some of these simple use cases with Go2 whenever that comes about. What I really like is the whole toolchain that comes with it. Fast compile times, cross-compiling, static binaries for easy deployment, gofmt, godoc, gocode, etc.
- pjmlp 12y ago
  > What I really like is the whole toolchain that comes with it. Fast compile times, cross-compiling, static binaries for easy deployment, gofmt, godoc, gocode, etc. If it also had an OS coded in it, it would be called Oberon (1992).
  - 0xdeadbeefbabe 12y ago
    The name Oberon would be easier to google too. An alarming number of false positives taught me to search for "golang" instead. A small baseline level of alarm is good when you are programming in go for obvious reasons, including {}interface etc.

djb_hackernews 12y ago

Go looks interesting. Anyone else not a fan of the single character variable names? Also, Is there a better way, in terms of clarity, to do this: <- c Even with the comment I would think the developer forgot to fill in the first half of that and assume it was a bug.

mattetti 12y ago
In the first version of the post I had _ = <- c To show that we don't use the value read from the channel, but someone in my team pointed that, that this isn't very idiomatic and mainly a way to explain what the code does to someone who doesn't know Go.

solojavier 12y ago

Thanks for sharing this Matt.. really good insight.