[permalink]Clean Code: Big Chunks of Code
2024-08-15 11:35
ccbcc
[permalink]
→ Understanding Clean Code: Functions ⚡
Sorry, but I strongly disagree. If you write a function and have it be called exactly only once, I dare to doubt the reason of existence of said function. I consider the call itself to be in the way. (Even if it's only because of the stack frame in memory and the extra line in the stack trace.) You may be better of with a raw file include (ugly!) or having the function be inline;. What I typically do is have a big block of comment above and below such a section with explanation what it does and what its relation to sections above and below is. (Using {$region} comes in handy here, as they are collapsed by default and may also provide 'overview readability' like the list of calls in the article, but without the code itself living somehwere else...)
It looks like good advice to split code in a series of calls, it looks like you're able to read from the list of names of functions that are called in sequence what is going on, but experience teaches this typically goes on an evolution of its own in the further progression of the project, and never sits quite right, causing more trouble than avoiding any. Especially when the functions themselves grow to do more things than their initial description.
What I usually do spend personal discipline on is making sure that the sections are independent among eachother, except for a limited set of references to objects that are operated on, and listed as such in the preceding comment. This is something that would get enforced by splitting in separate functions, but something that should emerge if you already think criticaly about the construction of larger chunks of code. Newer Delphi versions introduced the option to have a var section in a begin end; block, which could help with this, but I haven't grown accustomed to this yet. (Partly because I still keep a number of project fit to build with Delphi 7, sorry. The difference in file size of exe's and dll's is just too big.)
One more thing: In most cases, when I have sequences of code (sometimes tens of lines), that have to happen in sequence for a big operation (that sometimes get to hundreds of lines), each section get's its own try finally and/or try except, so you clearly know where something happens when something (inevitably) goes wrong at run-time.
This is ofcourse specific to Delphi (Object Pascal) and your milage may vary with other programming languages and development environments. It goes to show that its heritage goes back to Pascal which was designed to be a (theoretical) developer's language, and goes further back than C and its extensive family of languages that were primarily designed to be an evolution over assembler just so to get code to be cross-platform* and thus eliminating specific assembler as much as possible. (*: "cross-platform" here is PDP-7, Burrouhgs, Cray and punch-card-crunching machines from IBM; though it came in handy in the new Windows/
