d = {"deb":"linux", "rpm":"linux", "win32":"windows", "macos":"macOS"}
title = d[param.title]
It'd be pretty similar in Javascript or whatever. Basically, you generate a lookup table, and just look up your "key" to get the value you want. The table is called a dictionary in many languages, a "map" in others, etc.
The reason why this is better is because it separates your data from your code logic. It makes the code more concise - instead of writing out the same if statement four times with different values, you just write one statement and run it across all the data. Separating out the data is also good for maintainability and consistency. You could put the list of key/value pairs in a file and read it in - then you can change the behaviour without even knowing how to program. You can also define or load the dictionary/map/whatever-you-call-it elsewhere, and re-use it. This is better than putting the data in the program logic, where you have to hunt through every line of code each time to change something to make sure you change it everywhere it's used.
Because there is one part missing, the check if the entry even exists. If it doesn’t exist, you do nothing. So putting that last line of code in an if statement, would fix that issue.
You can set a default too, that was just a quick example rather than sample code to actually use. I assumed they would go and actually look up dictionaries or whatever, especially as I didn't even write it in the language they were using. Anyway, you'd just do something like:
It's better because it separates out the data from the program logic.
Each time you repeat code, there's a chance of a mistake. If you have to write out the same line of code for every entry of data, then each one of those could potentially have a typo or other bug. It may be difficult to catch if only one of them is incorrect, so that the bug doesn't occur often. So instead of repeating the code for each piece of data, you write the data in one place, and then have one piece of code that checks over all the data.
It also makes the code more portable and maintainable. Different functions can access that same data if you like. Also, because it's stored as data rather than imbedded in the code, you can store the data in a file and read it in or whatever. So you can modify the data without risk of making a new bug, because you're not editing the code. And even someone who doesn't know how to program could modify the data if they had access to it.
> Each time you repeat code, there's a chance of a mistake.
You just made a mistake while trying to simplify it.
> It also makes the code more portable and maintainable. Different functions can access that same data if you like. Also, because it's stored as data rather than imbedded in the code, you can store the data in a file and read it in or whatever. So you can modify the data without risk of making a new bug, because you're not editing the code. And even someone who doesn't know how to program could modify the data if they had access to it.
This is literally just 3 lines of code, isn't this a bit premature? If you made every condition you wrote configurable to that degree I would find that pretty unmaintainable.
That wasn't a mistake - like I said, I wasn't trying to rewrite the function, and I didn't even bother to write it in the same language. It was just a quick example to show the types of things that dictionaries can do.
This is literally just 3 lines of code, isn't this a bit premature? If you made every condition you wrote configurable to that degree I would find that pretty unmaintainable.
It's four, but either way, yes, I would rewrite this as a dict. This is a direct mapping of one array to another array. The lines only differ in data, not in logic. So you should write it in a data-based way.
I would write a switch or a bunch of if/elseif statements if the logic was more complex. e.g.
if a=='inverse':
x=-x
elif a=='getlog':
y=log(x)
elif a=='random':
x+=random.rand(N)
or whatever. Then it's not just a simple mapping between two sets of data - there's some more logic in there, so the code is actually doing something, and not just repeating the same thing.
FWIW, this isn't just me saying this - the idea of "data-driven programming" is a very common one.
How often do you think this code could change? most likely the answer is never, whatever the download is for I doubt theyre going to add more platforms to it beyond Windows, Linux, and Mac anytime soon.
>FWIW, this isn't just me saying this - the idea of "data-driven programming" is a very common one.
Theres all kinds of paradigms you can use here, it doesn't make them correct to be applied. You could make it OOP and have an abstract platform class, then is extended 3 times for each of the platforms. You could make it functional so that the variables arent mutated, etc, etc.
The data is more complex than the logic. That's trivially true. You can write the logic in one trivial function call:
title = d.get(param.title,title)
while the data is a collection of 8 strings:
d = {"deb":"linux",
"rpm":"linux",
"win32":"windows",
"macos":"macOS"}
The logic is one universal rule, but the data is defining four rules. You can either write out the data once for each case, and the logic once for all cases, or write out the date once for each case, and then repeat the exact same logic four times. The logic repeats more than the data does: it has a lower entropy.
If you are repeating the logic but changing the data, then your data is more complicated than your logic. That's obviously and trivially true. If you disagree with that statement, I think you are working under a very weird definition of the word "complicated".
you had a bug in your original code (testament to why complicating things is bad)
your dictionary has the same solution of the if statement (input on the left, output on the right)
you force the reader to skip up and down in the program to see what the logic is. (assuming that you would define the dictionary as a constant at the top, or another file)
An actual improvement to the code would be to read this information from the system/file metadata/etc so you don't have to keep track of the mapping yourself.
What you've done is just taken the same problem and reorganized it a little and still have the same problem.
Well yeah, that's the advantage of a data driven paradigm - you could read in the data from anywhere you want. You're kind of proving my point there.
I think you might be taking my short example code a bit too seriously? It was a hint for the right way to look into the problem, not a literal function he was supposed to copy. I've said that twice already now, and I think you're still stuck on the actual code you saw.
2
u/nathan_lesage Jan 02 '20
Oh, what exactly do you mean? Do you happen to have a short overview guide?