<p>Hi Guys,</p>
<p>I'm working on a talk on bad habits or design patterns C/C++ Developers bring to go. I'll appreciate if everyone could bring ideas of examples of some bad styles from C/C++ in Go.</p>
<p>Thanks,</p>
<hr/>**评论：**<br/><br/>dim13: <pre><p>You can write FORTRAN in any language.</p>
<p>Edit: wow! Thanks for gold, didn't expect it. ;)</p></pre>igknighted: <pre><p>I don't get the joke?</p></pre>thomasfr: <pre><p>It's probably very individual what types of design mistakes people makes
regardless where they come from.</p>
<p>I find that the general design error using go is not using interfaces where
they are a good fit but that's more general Go newcomer thing and not
specifically related to C/C++.. I came from a background of working with at
least 10 other imperative languages for many years and knowing when to reach
for the interface took some time.</p>
<p>From all Go code I have read the worst style offenders are people which
probably comes from a Java only background because some code sure has a lot of
unnecessary getters/setters and very verbose naming schemes which looks very
Java-like.</p></pre>grbler: <pre><p>at least they can't introduce memory leaks in Go... I have seen so many memory leaks in C++ code that I suspect came from Java programmers.</p></pre>thomasfr: <pre><p>Everyone can introduce leaks in C++ code :)</p>
<p>It's quite easy to not forget to free resources correctly in Go as well. Any go-routine, say an http handler which is fired off and never completes due to an io-wait or something. The memory leak is a side effect because the GC won't touch the data owned by the waiting go routine.</p>
<p>I accidentally allocated a new time.Ticker each 200ms instead of just using one instance once.. The memory leak is small but when I saw that the cpu usage increased somewhere around a % per day even though the request rate was about the same I looked it up and I had maybe (don't remember) hundreds of thousands of tickers being scheduled all the time :) I'm not sure if that leak would be fixed even today since the allocations were small enough to go by unnoticed if it weren't also messing with CPU time.</p></pre>grbler: <pre><p>Yeah, you're right. I didn't want to sound harsh (still the code I was talking about was very bad, many uses of <em>new</em> and no <em>delete</em>). I've certainly made mistakes in Go and C++ too. There are some particular things in Go, that are still pretty alien/unintuitive to me, and sometimes mistakes happen because I'm working with different programming languages.</p>
<p>E.g. the other day, a colleague wrote a <em>for</em> loop which contained a <em>switch</em> statement (it might have been <em>select</em>, but the following should apply to both). I knew Go had the <em>fallthrough</em> statement so you don't need to write <em>break</em> at the end of <em>case</em>-clauses. I assumed that <em>break</em> would break out of the <em>for</em> loop, which wasn't the case. We wrote a quick example at Go Playground to be sure.</p>
<p>In one of my Go programs I forgot a defer file.Close(); so most of the time it worked well (if you used it on directories that contained few files), but once I reached the limit for open file descriptors the program crashed. </p>
<p>edit: formating</p></pre>thomasfr: <pre><p>It's probably no coincidence that a member of the initial Go team proposed this change: require explicit labels for break, continue ( <a href="https://github.com/golang/go/issues/8591" rel="nofollow">https://github.com/golang/go/issues/8591</a> ).</p>
<p>I think I agree with Robert on this one.. I almost always add labels when I need break/continue just to make it extra clear to read the code. Sure it's annoying when all you want is a small loop which can break or continue but in practise almost all my Go code which uses break/continue's are kind of complicated node traversal stuff where loops and switch-statements nests into something which requires labels to be readable and possible to modify easy. I might also be remembering the more complicated uses more clearly since I've worked on them for longer periods of time than simpler ones, who knows...</p></pre>gotojikan: <pre><p>Golang has a lightweight syntax , the syntax itself inherits ideas from C such as pointers . Golang has a pass by value (Object) or pass by reference (*Object) a C progammer ( reflection on myself 2 years ago) I always (most of the time) used pointers to pass structs because it's faster than pass by value .
Alas in Golang things are different , and a mistake or misunderstanding that C programmers or C++ have is that passing by reference is faster ... Spoiler Alert : Not so much ,For example in Golang Maps and Slices are actually reference so they should be passed by value there is no need to pass them by using pointers , Golang uses escape analysis to figure out if an Object can be allocated on the stack which is much cheaper than allocating on the heap .</p>
<p>TLDR; Use Pass by value often for structs and always for maps and slices </p></pre>sagikazarmark: <pre><p>I think Go only has pass by value, pointers are also pass by value, not pass by reference (obviously the pointed value doesn't change when passing a pointer).</p></pre>SSoreil: <pre><p>One mistake is not using enough copying. Passing pointers around a lot is not as much of a performance or ease of writing thing in Go as it is in C or C++. Passing around copies of moderately sized data structures is surprisingly fast and makes code often easier to reason about and prove correct.</p></pre>mcandre: <pre><p>I mean, I personally think make unnecessarily restricts build platforms and encourages inefficient build workflows, so I’ve been structuring my Go projects against mage instead. The important thing is NOT to require any build system hijinks in order to compile a Go project, that would be stupid. Rather, aggregate common tasks like running linters and generating gox ports via mage tasks.</p></pre>adiabatic: <pre><blockquote>
<p>I’ve been structuring my Go projects against mage instead.</p>
</blockquote>
<p>For anyone else who might be tempted to search for this on the Web: <a href="https://magefile.org/">https://magefile.org/</a>, which is definitely not a mage build for Skyrim.</p></pre>
