Comments are harsh on what I took merely as a pedagogical example, but maybe it's because y'all have been burned so many times. I agree with you who advise to resist speculative programming. Don't write it till you need it, since all code incurs a burden of maintenance.
But I would like to address a tangent: extracting configuration from code. Let's take the article's example and change it a little. I'll decompose it, since it already has become a function, but often the first step is just a series of statements. (I will also port it to javascriptish pseudocode, since I don't know Julia.) So this might be your first draft:
response = HTTP.get('https://www.example.com/');
if (response.status !== 200) {
email('someone@example.com', 'something is wrong');
}
Instead of abstracting this into more general functions, I might simply move the literals to the top of the file:
url = 'https://www.example.com/';
ok = 200;
to = 'someone@example.com';
msg = 'something is wrong';
response = HTTP.get(url);
if (response.status !== ok) {
email(to, msg);
}
The only reason I know to do this is to maybe make changes easier. Even if you never need to generalize your code to other uses, you may need to update it for reasons outside your control. For example, someone leaves the company, and now you need to email someone-else@example.com. Or marketing changes the URL.
I don't know if there's any name about this specific refactoring change :-)
In general, it is best to create small functions that takes few dependent variables for the intended flexibility. The first judgment here is to decide whether a value should be a constant or variable. Constants would then be declared at the top, and variables come in as function arguments.
You reminded me that another pattern to handle this is to put some of these values as configuration parameters. For example, the email alert may need to be sent to different people for different environments - DEV, QA, and PROD.
In the grand-parent comment's example, you just want it to be more readable, because it is a once off block of code, so that whoever maintains it next can easily figure out what it is doing. Moving it into a function doesn't stop it from being a once off block of code, and we need to be careful not to increase complexity for the sake of it. By your last paragraph you had already introduced a configuration store and the concept of environments!
In all fairness, I led him that way. I called it "extracting configuration from code", which is reminiscent of #3 of the 12-Factor App (https://12factor.net/config).
You can extract config to various degrees. My example is perhaps the mildest: just group it together, near the beginning. You don't need complex frameworks. In fact this technique first caught my attention when I was reading other people's shell scripts.
The next step would be to move the config to its own file. This is very common in Linux. You have some tight binary, that is compiled and hard to change. But then you have config files, often with dozens of options. It's a nice way to do things.
The next step would be to move the config to a different level, no longer in a simple file. This is often either a relational database or environmental variables. Linux commands use environmental variables along with their config files.
For very large systems, this technique is the same in kind, just different in degree. You get fancy specialized systems, like Hashicorp Vault, to store your configuration, at least your secret ones, like passwords and stuff.
But I would like to address a tangent: extracting configuration from code. Let's take the article's example and change it a little. I'll decompose it, since it already has become a function, but often the first step is just a series of statements. (I will also port it to javascriptish pseudocode, since I don't know Julia.) So this might be your first draft:
Instead of abstracting this into more general functions, I might simply move the literals to the top of the file: The only reason I know to do this is to maybe make changes easier. Even if you never need to generalize your code to other uses, you may need to update it for reasons outside your control. For example, someone leaves the company, and now you need to email someone-else@example.com. Or marketing changes the URL.Is there a name for this kind of refactoring?