<p><a href="https://github.com/mrnickel/StaticSiteGenerator">https://github.com/mrnickel/StaticSiteGenerator</a></p>
<p>I've published a V0.1 of my first go project. It's another StaticSiteGenerator (yay!). Really wrote it in order to get my feet wet with something that I'm hoping to actually use (ya, another person who will likely fail at writing blog content regularly haha).</p>
<p>Some of the things I'm still not satisfied with:</p>
<ul>
<li><p>File layout. What's the "idiomatic" way of layout out packages / files in Go? Seems like the wild wild west to me!</p></li>
<li><p>Polluting packages. I'm used to languages like Java where I can hide my private helper functions inside of a class without polluting the codebase... Go doesn't seem to work like that</p></li>
<li><p>things I just don't know!</p></li>
</ul>
<p>Any / all feedback would be GREATLY appreciated. Again, I don't expect people to ACTUALLY use this project. Just wrote it for myself.</p>
<p>Thanks!</p>
<hr/>**评论：**<br/><br/>driusan: <pre><p>It took me a while to figure out how the file layout works in Go, but basically:</p>
<ol>
<li>everything goes under $GOPATH/src/$packagename</li>
<li>$packagename should be the full go get url (ie github.com/mrnickel/StaticSiteGenerator, <em>not</em> just StaticSiteGenerator), even locally</li>
<li>Do all your work locally in $GOPATH/src/github.com/mrnickel/StaticSiteGenerator</li>
<li>You can organize the packages and subpackages however you want inside your github repository, but make sure your import statements contains the whole go get style URL (ie github.com/mrnickel/StaticSiteGenerator), and you work locally in $GOPATH/src/github.com/mrnickel/StaticSiteGenerator.</li>
</ol>
<p>When I started, I kept trying to put things locally in ie $GOPATH/src/StaticSiteGenerator, and then the code didn't work the same after checking it out with go get, and it took me a while to figure out that you're expected to organize things this way. Once I figured out that on my local filesystem I had to organize it the same way that go get would retrieve them, things started making more sense.</p>
<p>It also wasn't obvious to me at first that "package main" is an exception to the rule that packages need to go in a directory with the same name as the package name. If the package name is "main", then go build will compile it into a binary with the same name as the directory name.</p></pre>kjk: <pre><p>Too Many Packages syndrome. Not unsurprising given Java background. They mention this in <a href="http://blog.golang.org/organizing-go-code:">http://blog.golang.org/organizing-go-code:</a></p>
<p>"On the other hand, it is also easy to go overboard in splitting your code into small packages, in which case you will likely becomes bogged down in interface design, rather than just getting the job done."</p>
<p>There's no value in putting constants in their own package. It's just more typing for you.</p>
<p>Another rule of thumb is package groups independent, re-usable parts of the code. A re-usable logging machinery? Put it in the package.</p>
<p>In your particular case, stats depends on post on constants etc. They are all inter-dependent. There's no need to have any package there because all code is logically part of the same app and there's no code that could be re-used by another app.</p>
<p><a href="https://github.com/russross/blackfriday">https://github.com/russross/blackfriday</a> is the most popular Markdown renderer in Go, probably better tested and more feature-ful than the one you're using.</p></pre>earthboundkid: <pre><p>If you haven't already, look at <a href="https://github.com/spf13/hugo" rel="nofollow">https://github.com/spf13/hugo</a> for inspiration and general feel for how things are organized in a well regarded Go-project.</p></pre>lattakia: <pre><blockquote>
<p>Polluting packages. I'm used to languages like Java where I can hide my private helper functions inside of a class without polluting the codebase... Go doesn't seem to work like that</p>
</blockquote>
<p><a href="https://golang.org/ref/spec#Exported_identifiers" rel="nofollow">https://golang.org/ref/spec#Exported_identifiers</a></p></pre>MrNickel187: <pre><p>I knew of exporting identifiers based on case sensitivity, I mean't more specifically everything within my Post package having access to the postDraft(...) function as defined here <a href="https://github.com/mrnickel/StaticSiteGenerator/blob/master/post/post_from_file.go#L86" rel="nofollow">https://github.com/mrnickel/StaticSiteGenerator/blob/master/post/post_from_file.go#L86</a></p></pre>driusan: <pre><p>Why do you want to hide your function from yourself? You have control of your package, and you don't need to worry about users calling it if it's unexported.</p></pre>lattakia: <pre><p>+1</p>
<p>The simplicity of Go is that you can dispense with the complexity of Java's public, private, package and protected access modifiers.</p></pre>fxnn: <pre><p>And yet your code base can pollute quickly if any func can simply access anything.</p></pre>skarlso: <pre><p>Good job working on a larger project! Go forth and spread the Golove. :)</p></pre>mwmahlberg: <pre><p>My concern is usability and code maturity here.</p>
<p>I'd appreciate if there was some sort of "newsite" command, which sets up the expected directory structure.
A default template would be nice. Maybe a small example on how to build one in the wiki?</p>
<p>When the StaticSiteGenerator is called without command, it simply panics – bad idea. You should always check user input, and especially when accessing a slice of unknown size.</p>
<p>Regarding CLI: You might want to have a look at <a href="https://github.com/spf13/cobra" rel="nofollow">https://github.com/spf13/cobra</a>, which allows pretty neat cli features, including automatically generated help messages, advanced flag parsing and alike.</p>
<p>Last but not least: golint and go vet seem pretty happy with your code, so it should not be too much of a work to get the stuff done I suggested ;)</p></pre>fxnn: <pre><p>Seems like you don't organize your code in structs. That helps me not to "pollute" my packages with private funcs -- similarly to how we organize Java code in classes.</p></pre>MrNickel187: <pre><p>I <em>think</em> that I organized my Post struct <a href="https://github.com/mrnickel/StaticSiteGenerator/blob/master/post/post.go" rel="nofollow">https://github.com/mrnickel/StaticSiteGenerator/blob/master/post/post.go</a> however my worry is that these structs will get pretty large...</p></pre>fxnn: <pre><p>Well, but that's a problem you'd have in Java, too. You could have a Post class there, having mehods for anything that could ever happen to a Post. Or you could have something like an UpdateHandler or a RenderHandler that would do whatever has to be done with the post.</p>
<p>Same in Go. Structs are not only data, but also behavior. They can even have no data, as with <code>type myStruct struct {}</code>. Organizing my code this way always helps me, from the very beginning of a project.</p></pre>
