5 ms·

> all in a single file It's not really an advantage, is it? Having everything mixed up into one giant file just makes the code much harder to make sense of.

jerf 7y ago
As feedback to the author, since the author seems to also be the HN poster, I would agree with this. If it were the only meaningful file in the project, maybe it'd be worthwhile, but at 885 lines, this could stand to be broken into segments. What I'd suggest then is adding a section to the README.md that functions as a reading guide for the code; start here, read this, here's what each file is doing, here's where this sample app is, here's that one, etc.
- Nextgrid 7y ago
  I agree. “Single file” projects are good for education if they’re short, but that many lines is just counter-productive.
- photon_lines 7y ago
  Thank you for the feedback!! The main.go file has comments within it that try to explain what each component does, and I tried to structure it in a way that makes it very easy to conceptualize and understand. Whenever I write code, I do my best to make it self-documenting, although doing this isn't necessarily easy and I may have done an inadequate job in this instance. I'll see if I can find some time and include more info in the README.md - once again, if you read my previous response to the parent comment: the reason I included everything in one file was because of my preference, as I prefer to have everything in one place when learning something. The focus of this was teaching and demoing Go functionality, not shipping production ready code!
save_ferris 7y ago
I recently started learning go and I've been struggling with the lack of modularity across smaller codebases like this. For all of the great tooling around formatting go, I'm kinda surprised by some of the code organization decisions I see.
- jerf 7y ago
  There's some differences in style. I take a very aggressive stance on separating my modules; my thought is that it's relatively easy to understand what any given module is doing if it is small and focused and clearly pulls in its dependencies. But it's a non-trivial challenge to keep it all so nicely isolated and avoid loops. Worth it, I think, or I wouldn't do it, but non-trivial. There are also a lot of people who pretty much just punt and put everything in one module, so they don't have to deal with circular issues. I'm not sure I see a clear community consensus.
- w0uld 7y ago
  I found the advice in Brian Ketelsen's 2018 GopherCon talk[1] helped my Go code organization. It helped me reason about the optimal way to abstract my code. [1] https://www.youtube.com/watch?v=MzTcsI6tn-0 https://www.youtube.com/watch?v=MzTcsI6tn-0
deleted 7y ago
[deleted]
photon_lines 7y ago
I completely agree, although that also depends on what you're going for. My personal preference when learning something is to have everything in one place. That way, I can easily scan through the components and see the whole piece rather than having to switch windows. I agree though that it's definitely not a best practice if you're focusing on writing and delivering production code. The focus of this app was actually showing some neat Go features and delivering a fully functional web server in a singe file. If you look through the code, you'll see that I added a lot of comments and even made notes stating that even though I included the raw HTML/CSS/JS components within main.go, this definitely was not a best practice and I referenced files within the repository which contain this code in case anyone decided that they wanted to refactor and clean it up. Anyways, hopefully this helps and thanks for the feedback!
linsomniac 7y ago
We use a Go app called MailHog, which is a SMTP server for development use. It also has a web interface for management. All in a single go file (SMTP server, HTTP server, plus all web artifacts). That is a pretty convenient packaging for a dev/staging tool.
- w0uld 7y ago
  Do you mean a single binary file? MailHog's mail.go file pulls in a number of dependencies that round out its HTTP and SMTP servers. In OP's case, the entire project's source code is in the main.go file.
  - linsomniac 7y ago
    Yes, a single binary file is what I meant. I realize in some ways it is orthogonal here, but I guess it reminded me that sometimes a single file can be useful in surprising ways...
user5994461 7y ago
There is a widely popular web server in python that is a single file. I find it quite readable and it's well documented. It helped me immensely on a few projects where there was no dependency management to speak of, or wasn't allowed to use external dependency. Copy a single file and done. https://github.com/bottlepy/bottle https://github.com/bottlepy/bottle

jerf 7y ago

As feedback to the author, since the author seems to also be the HN poster, I would agree with this. If it were the only meaningful file in the project, maybe it'd be worthwhile, but at 885 lines, this could stand to be broken into segments. What I'd suggest then is adding a section to the README.md that functions as a reading guide for the code; start here, read this, here's what each file is doing, here's where this sample app is, here's that one, etc.

Nextgrid 7y ago
I agree. “Single file” projects are good for education if they’re short, but that many lines is just counter-productive.
photon_lines 7y ago
Thank you for the feedback!! The main.go file has comments within it that try to explain what each component does, and I tried to structure it in a way that makes it very easy to conceptualize and understand. Whenever I write code, I do my best to make it self-documenting, although doing this isn't necessarily easy and I may have done an inadequate job in this instance. I'll see if I can find some time and include more info in the README.md - once again, if you read my previous response to the parent comment: the reason I included everything in one file was because of my preference, as I prefer to have everything in one place when learning something. The focus of this was teaching and demoing Go functionality, not shipping production ready code!

save_ferris 7y ago

I recently started learning go and I've been struggling with the lack of modularity across smaller codebases like this. For all of the great tooling around formatting go, I'm kinda surprised by some of the code organization decisions I see.

jerf 7y ago
There's some differences in style. I take a very aggressive stance on separating my modules; my thought is that it's relatively easy to understand what any given module is doing if it is small and focused and clearly pulls in its dependencies. But it's a non-trivial challenge to keep it all so nicely isolated and avoid loops. Worth it, I think, or I wouldn't do it, but non-trivial. There are also a lot of people who pretty much just punt and put everything in one module, so they don't have to deal with circular issues. I'm not sure I see a clear community consensus.
w0uld 7y ago
I found the advice in Brian Ketelsen's 2018 GopherCon talk[1] helped my Go code organization. It helped me reason about the optimal way to abstract my code. [1] https://www.youtube.com/watch?v=MzTcsI6tn-0 https://www.youtube.com/watch?v=MzTcsI6tn-0

deleted 7y ago

[deleted]

photon_lines 7y ago

I completely agree, although that also depends on what you're going for. My personal preference when learning something is to have everything in one place. That way, I can easily scan through the components and see the whole piece rather than having to switch windows. I agree though that it's definitely not a best practice if you're focusing on writing and delivering production code. The focus of this app was actually showing some neat Go features and delivering a fully functional web server in a singe file. If you look through the code, you'll see that I added a lot of comments and even made notes stating that even though I included the raw HTML/CSS/JS components within main.go, this definitely was not a best practice and I referenced files within the repository which contain this code in case anyone decided that they wanted to refactor and clean it up. Anyways, hopefully this helps and thanks for the feedback!

linsomniac 7y ago

We use a Go app called MailHog, which is a SMTP server for development use. It also has a web interface for management. All in a single go file (SMTP server, HTTP server, plus all web artifacts). That is a pretty convenient packaging for a dev/staging tool.

w0uld 7y ago
Do you mean a single binary file? MailHog's mail.go file pulls in a number of dependencies that round out its HTTP and SMTP servers. In OP's case, the entire project's source code is in the main.go file.
- linsomniac 7y ago
  Yes, a single binary file is what I meant. I realize in some ways it is orthogonal here, but I guess it reminded me that sometimes a single file can be useful in surprising ways...

user5994461 7y ago

There is a widely popular web server in python that is a single file. I find it quite readable and it's well documented. It helped me immensely on a few projects where there was no dependency management to speak of, or wasn't allowed to use external dependency. Copy a single file and done. https://github.com/bottlepy/bottle https://github.com/bottlepy/bottle