31–40 of 101 posts
Earlier quoted context omitted.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
Quite the opposite, I hate it when projects have dozens upon dozens of modules with 1 function. Multiple huge files are the best sweet spot. (Only crazy adn exceptional things like putting everything into a single file damages the readability imho)
Earlier quoted context omitted.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
While I'm not sure that was a consideration here, sometimes C compilers produce better machine code when they got access to more function definitions. Eg. Sqlite recommends that embedders use the single ~10mb sqlite.c file[1] for both ease of use and performance reasons. [1]: https://www.sqlite.org/amalgamation.html
Earlier quoted context omitted.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
5000 lines looks like half are comments or whitespace, none of the functions look more than a couple hundred lines or a few levels of control flow depth. Pretty harsh nitpick.
Earlier quoted context omitted.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
I get the impression that long files are culturally acceptable in systems-level C code. E.g., just a cherry-picked file from Linux: kernel/sched/core.c is over 11k lines. https://github.com/torvalds/linux/blob/master/kernel/sched/c...
Earlier quoted context omitted.
Actually I don’t mind big files. It is simpler scanning through it or doing a quick search than if you had a bunch of smaller files. And 5000 lines is not awkward for most editors, especially as many editors have the ability to collapse functions.
This feels like a good area for tooling (editors, source hosts, SCM extensions) to improve experience. I don’t always mind large source files (and sometimes may prefer them over large file system hierarchies), but the can be a pain to navigate in some circumstances. As an example, making several related changes in very different parts of a file, where you need to cross-reference between them. The changes themselves m…
Earlier quoted context omitted.
Actually I don’t mind big files. It is simpler scanning through it or doing a quick search than if you had a bunch of smaller files. And 5000 lines is not awkward for most editors, especially as many editors have the ability to collapse functions.
This feels like a good area for tooling (editors, source hosts, SCM extensions) to improve experience. I don’t always mind large source files (and sometimes may prefer them over large file system hierarchies), but the can be a pain to navigate in some circumstances. As an example, making several related changes in very different parts of a file, where you need to cross-reference between them. The changes themselves m…
This is exactly how vim buffers work (for instance in a split) work.
Earlier quoted context omitted.
5000 lines looks like half are comments or whitespace, none of the functions look more than a couple hundred lines or a few levels of control flow depth. Pretty harsh nitpick.
The point of calling it a nitpick was to indicate precisely that my comment wasn't meant to be taken harshly.
Earlier quoted context omitted.
Software has bugs. Sometimes they're missed in testing. Do you hold the software that you write to the same standard?
To be fair, I think most users of Postgres hold it to a higher standard than the software they write themselves, and reasonably so. Postgres has developed a sterling reputation for reliability, and this does tarnish it somewhat. (Not by much in my personal view, but not zero either).
It’s not like other database products haven’t had very similar issues, either [https://support.microsoft.com/en-us/topic/fix-data-corruptio...]
Hell, last night I literally had a MSSQL server where Windows Server Failover Clustering randomly decided to delete all of the AlwaysOn Availability Group configurations from the node; along with random NTFS corruption (no unclean shutdown, SAN is fine) resulting in us having to restore master and msdb from backups before we could rejoin it to those AGs.
Bugs happen.
Looking at the file with changes https://github.com/postgres/postgres/blob/master/src/backend... , I have to say this source code repository is so well documented/commented and structured, I really gives you a huge trust in postgres to be used in your stack.
Large C codebases _have_ to be exceptionally nice, or they immediately collapse under their own weight. As a dev team, the language teaches you this the hard way. I've never seen a terrible huge C codebase (but have seen many in other languages).
I have 100% confidence they exist. They just don't get uploaded to Github out of shame or embarrasment.
Earlier quoted context omitted.
Actually I don’t mind big files. It is simpler scanning through it or doing a quick search than if you had a bunch of smaller files. And 5000 lines is not awkward for most editors, especially as many editors have the ability to collapse functions.
This feels like a good area for tooling (editors, source hosts, SCM extensions) to improve experience. I don’t always mind large source files (and sometimes may prefer them over large file system hierarchies), but the can be a pain to navigate in some circumstances. As an example, making several related changes in very different parts of a file, where you need to cross-reference between them. The changes themselves m…