“What if it changes?”

Re:“What if it changes?” by orthoxerox on Monday May 23, 2022 @04:09AM (#31476435)

> This is a terrible advice. According to this, a classic program that loads data from a file, processes it, then writes the results to another file should be a single giant main() that mixes input parsing, computation and output formatting. Assuming file formats don't change, all of those would be used only once. CS 101 style. :D

Yes, if the program will be written and tested exactly once, with no change requests to come later, it's perfectly fine to write it as one big main().

It all depends on what the stakeholders need, clear communication with them is the real trick.

[ Parent | on HN ]

Re:“What if it changes?” by pkolaczk on Monday May 23, 2022 @06:01AM (#31477052)

Well, what if the program suddenly crashes and gives you a stacktrace pointing to main()? Assuming you were not the original author of the code, you'd have to read most of the code to understand it.

If the main was split into well defined, separate pieces, at least you could quickly rule out quite a lot of complexity. If it crashed in parsing, so wouldn't need to understand the processing logic, etc.

Sure it is easy to read one blob of code, if it is only 100 lines of code. But it is a different story if it is 10000 lines and now you have to figure out which of the 100 variables are responsible for keeping the state of the input parser and which are responsible for "business logic".

[ Parent | on HN ]

Re:“What if it changes?” by orwin on Monday May 23, 2022 @06:15AM (#31477129)

But writing it would be harder, no?

I mean if it's only like 50 short lines, that would be okay-ish, but in this case why do it in C and not use perl or awk?(i suppose you want fast text processing, so I won't suggest python). If the processing is hard, then you will need debugging (which is better in segregated functions) and to prototype a bit (unless I'm the only one who does that?).

[ Parent | on HN ]