News for hackers. Stuff that matters.
Re:Important PostgreSQL 14 update to avoid silent corruption... by gnulinux on Thursday June 09, 2022 @08:27PM (#31688615)
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)
Re:Important PostgreSQL 14 update to avoid silent corruption... by colordrops on Thursday June 09, 2022 @11:11PM (#31689533)
Files with one function vs files with 5000 lines are not the only two options.
Re:Important PostgreSQL 14 update to avoid silent corruption... by fjfbsufhdvfy on Friday June 10, 2022 @12:41AM (#31690129)
I've got it! We could use files with one function that spans 5000 lines.
Re:Important PostgreSQL 14 update to avoid silent corruption... by colordrops on Friday June 10, 2022 @02:10AM (#31690658)
How about a function that spans 5000 files
Re:Important PostgreSQL 14 update to avoid silent corruption... by pcthrowaway on Friday June 10, 2022 @02:38AM (#31690812)
Why even use 5000 lines when you you can often combine them all into one line.
Re:Important PostgreSQL 14 update to avoid silent corruption... by pmontra on Friday June 10, 2022 @03:01AM (#31690962)
That's the job of the compiler, then we can use a disassembler to read the actual optimized source code.
Re:Important PostgreSQL 14 update to avoid silent corruption... by osigurdson on Thursday June 09, 2022 @10:19PM (#31689273)
300 to 1000 lines per file is best IMO.
Re:Important PostgreSQL 14 update to avoid silent corruption... by wahern on Friday June 10, 2022 @01:30AM (#31690406)
IMO, paintings with the color blue are the best.

What does number of lines have to do with anything?

Re:Important PostgreSQL 14 update to avoid silent corruption... by rgoulter on Friday June 10, 2022 @03:58AM (#31691304)
At each extreme:

A source code file with very few lines will mean more cognitive load is required to remember which file (or package) some functionality is, and likely more effort to maintain the code.

Whereas, source code files which are very large mean more cognitive effort to remember where in the file some function is. In many languages, variables can be local to a file, which means use of such variables is riskier, etc.

It may be desirable to combine smaller files into a more coherent whole, or to split up an overly complicated large file into several smaller files.

Sure, without seeing code, I don't think you can come up with a concrete rule which exists in all cases. Rules of thumb can still be useful as an indication of maintenance effort.