This is one of those "software engineering best practices" that sounds nice but has no basis in reality. What matters is the formal structure of your program: types, composition, state, capabilities. Where your code is located on the filesystem is incidental complexity.
> This is one of those "software engineering best practices" that sounds nice but has no basis in reality
Are you a programmer? What languages?
> Where your code is located on the filesystem is incidental complexity.
Incidental complexity is still complexity to deal with.
It isn't easy for me as a developer to find such and such routine if you've thrown everything into a big bucket named "main".
You also omitted the fact that I didn't only refer to files. I mentioned the size of functions, too. Now functions ARE logical units of code, and if you need to scroll ten screens and names are as vague as "ProcessEvent" (which is not broken down into subroutines), this doesn't speak very well about the overall design.
Thanks for the links - but it's hard not to notice that they both refer to FP languages, however (Erlang and Scala).
I wouldn't step out to judge the quality of an Erlang codebase, because that's not a paradigm I'm well familiar with.
Go, however, doesn't belong to that family. I see no reason why SRP and other oldschool principles wouldn't apply here. I'd be happy if someone told me (that's why I asked at the beginning - "or is that the language"?).
The other commenter (@mod) implied that since the project is experimental, it's done quick and dirty but that's because it's prototyping.
Note that I've never said the author of the project is a sloppy programmer, I only wondered at the code being so messy.
Considering a major goal of the project / approach is precisely to deprecate the the hierarchical and file-based approach to programming, it doesn't really surprise me to find all the code in a single file.
Perhaps the better storage layer would be function definitions living in a database. That Conception uses an unindexed flat file as the 'code database' also isn't surprising given the stage of development.
I get paid to program c, c++, java, python, and r (not necessarily in that order, with other languages as needed) and there's nothing inherently wrong with a 500 line method if that's what the problem calls for.
It's grounds for getting the stink-eye in code review, but to reject it out of hand is pure ideology.
"there's nothing inherently wrong with a 500 line method if that's what the problem calls for"
Yeah, "if", but that's rarely the case :) Care to show me an open-source example of a function 500 lines long where you don't think one could find proper seams to split the code along? Ideally in https://github.com/shurcooL/Conception-go/blob/master/main.g...
My thinking is more along the lines of http://erlang.org/pipermail/erlang-questions/2011-May/058768... and http://tonymorris.github.io/blog/posts/identifier-names/, but I bet your professional literature would be apopleptic at suggestions like these :]