331–340 of 352 posts
Earlier quoted context omitted.
Can't be many languages where that matters in 2022. Auto-inlining of short functions was a thing in the 1990s.
This may be true for compiled langs. In interpreted langs this is not the case. Function calls in Python for example are notoriously expensive.
Earlier quoted context omitted.
> Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Without seeing something else, e.g…
> How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Only if they're randomly named. > Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. Seeing a table named "invoices", which has a column named…
Earlier quoted context omitted.
What is easier to read: a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 b) 20 If all the code in your project was written like a), how would you feel? Does it make your job easier or harder? I'll tell you how most people feel when they read code that looks like a): - The author didn't care about other maintainers. - The author is selfish and does not have empathy for others. - The aut…
Your example is artificially designed to make your point, but imagine a case like this: # Add the left & right margins width = calculatedWidth + 1 + 1 The "+1+1" might indeed be more readable than "+2".
Earlier quoted context omitted.
I'm working on a project that is following Uncle Bob's Clean Code guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it. My initial prejudices have largely held. I do find the code harder to read and follow. Having to jump around, follow variables that change name as they are passed through functions, keeping track of state that was moved to a c…
>guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it. Dont feel bad about it Those small functions with hard limits are just terrible advice When you gotta know functions impl., which for me is very often Then this approach just increases cognitive load
People seem to be passionate about their answers, now I want to get the programmer psychology book and see if there's data about people being more effective with or without a lot of small functions.
Earlier quoted context omitted.
> Each function becomes something new that needs to stick in your brain. But if you don't put it in a separate function, then all that code becomes something that you have no choice but look at as part of this function, because the text of it is right there in the function. Sticking part of the code in a sub-function gives you the choice: Do I trust that this function does what it says, with no other effects that I h…
I like putting comments above paragraphs of code so that you can skim it by trusting the comments, but you can also inspect any individual paragraphs implementation without losing your context.
Earlier quoted context omitted.
My opinion is that you can write code that's easy to understand, and it is also good for the computer to run. One thing is not in contradiction with the other. It could lower the reusability of the code, by not having many abstractions, but it will be easy to understand, concise, and it will do what it was written for very well.
It should be written so it's easy for humans to understand first. If that's too slow, then it can be optimized so it's fast, if a bit less readable. 9 times out of 10 it won't be too slow in the first place these days, unless you know beforehand that you need maximum speed for valid reasons.
That complete disregard for performance is what gave us the endless Electron clients eating CPU/RAM just to do basic chat and music playing stuff.
If the code is written with care for both things, readability and speed, the actual state of things would not be so wasteful. You don't need to make it difficult to understand. Just don't disregard performance as an afterthought.
Earlier quoted context omitted.
Any way to do that in Python? Basically an anonymous function across multiple lines, which can be collapsed in the IDE view?
Python's lambdas can have as many lines as you want. Just wrap parens around it. Hissp uses this form as a compilation target. Its REPL shows the Python compilation. Play around with it til you get it: https://github.com/gilch/hissp
While you can have multiple lines, you are not allowed to have multiple statements.
Nobody wants to write code chained together with ternaries and and-operators. When someone says multi-line lambdas, what people actually mean is multi-statement lambdas.
Now I know where Rust got some of its syntax from... As an aside, when I see samples like this, it makes me itchy . I hope and assume that they're being used as made-up snippets just to illustrate a point, and aren't being lifted from an actual codebase. Because... ugh ... isn't it obvious? Attacker-controlled input such as URLs should never be manipulated with naive string processing! Always use a proper parsing lib…
Earlier quoted context omitted.
> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function. Where this breaks down is when the code you're trying to split out is not at a different level of abstraction,…
Each function becomes something new that needs to stick in your brain. Someone that applies "MORF" to their code winds up nearly inventing their own language in the file that they're writing. All that takes up more memory when you're reading their code, because due to leaky abstractions the actual implementation of whatever the function name that you replace it with is often important. I have an actual track record o…
Earlier quoted context omitted.
> How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Only if they're randomly named. > Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. Seeing a table named "invoices", which has a column named…
It gives clues, but it doesn't tell the whole story. It certainly isn't enough to do anything other than make a pure guess at what the application actually does and more importantly how it does it.
I'm not claiming that it will tell the whole story; I am claiming that it tells so much more of the story than the code, that you may as well just not look at the code if you have the data structures.
OTOH, if you look at only the code and not the data structures, you'll have so little of the story that you cannot make any change without risk of breaking some other piece of logic.
There's just no comparison between "The code tells us what the applications should do" and "The data tells us what the applications should do".
If you can find any examples where it is faster to determine what business logic is supported by the application by examining code (as opposed to being faster to determine what business logic is supported by examining the data structures), I'd very much like to see that.