111–120 of 352 posts
Earlier quoted context omitted.
I'll just leave this here: https://github.com/KxSystems/kdb/blob/master/c/c/odbc.c
And that's... bad? Culture shock, sure, but this looks like fairly clean APL-style C to me. I would have wrapped some of those lines though.
This rewrite is more performant than the original: query_params = s.split('?')[1].split('&')[-3:] map(lambda x: x.split('=')[1], query_params) The calculation of query_params, having no dependency on the lambda parameters or anything being mutated, has been lifted out of the lambda, and thus spared from repeated execution by map. The compiler for that language won't do this automatically.
The query params were never in the lambda to begin with. Python function calls have strict (not lazy) semantics, i.e. "applicative order", i.e. both expressions passed as arguments to map() are evaluated before the map body gets them as parameters, thus the query params would only be evaluated once, even when inlined as they were originally.
Same with the lambda definition: it's evaluated only once. It's just the lambda body that gets reevaluated each loop, and only evaluated for the first time on the first loop.
I like how this article explains that "clean" must be "readable for humans". However, the concerns raised are only superficial. It's much more important to get the larger scale structure right. I recommend drawing diagrams and explaining the architecture to humans. Then again, I'm not saying overdo it, because some things are hard to draw, some are hard to explain. In the end, it's important to get a complete underst…
In that context, I don't think this is superficial at all. If your code is hard to read, I suspect your design is hard to read too.
Sure, for super important architecture decisions you have to make a few top-down (spatial partitioning structures, database decisions, network architecture, etc.), but I think it's generally better to late-bind on those decisions if you can.
Earlier quoted context omitted.
And that's... bad? Culture shock, sure, but this looks like fairly clean APL-style C to me. I would have wrapped some of those lines though.
Of course it's bad. Is that a serious question?
Your cultural prejudice is showing. There are good reasons APL is written the way it is, and this example is simply bringing those benefits to C by writing it in the dense APL style. There are other APL derivatives, like J[1] that are written in C the same way. These projects are well-maintained. They aren't collapsing under a load of technical debt. The style works. To them, it's clean code.
Early in my career, I took to heart such books and articles and often felt guilty and lessor-programmer when I cut corners. Here's my 2 cents now: - Some of this is the coding equivalent of "6 rules for financial freedom" or "6 ways to find your dream soulmate". Generic advice that doesn't reflect highly nuanced reality. - These rules are guidelines at best. There are justifiable reasons to break them; which I do oft…
What irritates me the most are the long, non-linear comments full of distracting noise. It's like reading a choose your own adventure novel.
Earlier quoted context omitted.
> Show me your flowcharts (code) and conceal your tables (data structures), and I shall continue to be mystified. Show me your tables (data structures), and I won’t usually need your flowcharts (code); they’ll be obvious. -- Fred Brooks, The Mythical Man-Month , 1975 > a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas abo…
The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs.
I don't necessarily agree with the step of putting the code in a separate function; that often works, but just as often makes it so that the code can't be read top-to-bottom anymore which hurts readability. In this case there's, I think, a better alternative; the equivalent-ish code in Ruby for the example code here would be something like this: values = s .partition('?')[-1] .split('&') .map { |key_value| key_value.…
> 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,…
It's also definitely related to testability for me. If I'm pulling out the right details, then I'll often get a nice cluster of tests that pin down the higher-level concept in a way where it's both the production and test code that gets more readable.
Reminded me of 'Object Calisthenics' by Jeff Bay. Basically an exercise for a toy project where you adhere to 9 rules: 1. Only One Level Of Indentation PerMethod 2. Don’t Use The ELSE Keyword 3. Wrap All Primitives And Strings 4. First Class Collections 5. One Dot Per Line 6. Don’t Abbreviate 7. Keep All Entities Small 8. No Classes With More Than Two InstanceVariables 9. No Getters/Setters/Properties https://william…
Gah. I've seen the other side of this, a few people far too trigger happy to make FivePlusVeryLongNounVO/DTO for every little thing, and it gave me some new appreciation towards tuples and primitives. Sometimes you really don't want to go into another new file for an object type which is used in only one specific place. Especially with
>Don’t Abbreviate
Meaning the variable name will end up long anyway. With tuples, you get deconstruction without the hassle, too.
I enjoyed the article and agreed that working memory places a fundamental limit on the intelligibility of otherwise equivalent pieces of code. As a former psychologist with experience of memory research (though not quite this area), it might be useful to others if I add that: - The size of the short-term store is normally said to be 7 plus or minus 2 (the 'magic' number 7) - The Working Memory model has somewhat over…