When are they planning on updating the simple sabotage field manual pdf?
What makes code hard to read: Visual patterns of complexity (2023)
271–280 of 383 posts
Re: What makes code hard to read: Visual patterns of complexity (2023)
#272I think the only one I disagree with here is the function chains example. I may agree with a different example, but with this one I find the chained version without variables much easier to understand because I'm traversing the graph visually in my head, while the variables are additional state I have to keep track of in my head. ---- Really I was hoping this would be about actual visual patterns and not syntax. It's…
When vertical alignment helps readability, you have use `#fmt: on/off`. Black simply doesn't have enough information to know when assignment alignment (or comment alignment) was done on purpose.
Re: What makes code hard to read: Visual patterns of complexity (2023)
#273The notion of "readable code" involves 2 parties: a) The skill level of the person who produces the code b) The skill level of the person who reads the code. Most of the time, we tend to blame the a) person.
This is true, but it is more nuanced than that. It also has to do with familiarity with common patterns and willingness to accept that not everyone has the same style you do.
Re: What makes code hard to read: Visual patterns of complexity (2023)
#274My pet peeve: function getOddness4(n: number): if (n % 2 === 0): return "Even"; return "Odd"; While it is shorter, I prefer vastly prefer this one: function getOddness2(n: number): if (n % 2 === 0): return "Even"; else: return "Odd"; Reason: getOddness4 gives some sense of asymmetry, whereas "Even" and "Odd" are symmetric choices. getOddness2 is in that respect straightforward.
90% of the time I prefer the first. I am allergic to indentation and I hate anything remotely like: function foo(a) { if (a) { return doThing() } else { return Error(); } } I like all of my assertion and predicate guards nicely at the top of a function: function foo(a) { if (!a) { return Error() } return doThing() } And for that reason, I would probably go for getOddness4 even though I see your point.
In case of handling exceptions (and similar stuff), I also prefer avoiding unnecessary nesting.
For two (or more) equally valid, I prefer keeping same nesting.
Re: What makes code hard to read: Visual patterns of complexity (2023)
#275Earlier quoted context omitted.
I 100% agree with this. One of the best compliments I ever got (regarding programming) was from one of my principal engineers who said something along the lines of "your code reads like a story". He meant he could open a code file I had written, read from top to bottom and follow the 'narrative' in an easy way, because of how I'd ordered functions, but also how I created declarative implementations that would 'talk'…
There’s a difference between simplifying a concept and stating it plainly. I use this analogy a lot. Code can be like a novel, a short story, or a poem. A short story has to get to the point pretty quickly. A poem has to be even more so, but it relies either on shared context or extensive unpacking to be understood. It’s beautiful but not functional. And there are a bunch of us short story writers who just want to ge…
I see where you are coming from but that's unnecessarily hostile.
> There’s a difference between simplifying a concept and stating it plainly.
You are right, but they are not mutually exclusive.
The analogy you used with novel, short story, and poem/haiku also doesn't demonstrate your point: it's not like you can compress any novel into a short story, let alone a poem. If you're into games, try equating AAA-quality 3D games to novel, high-resolution 2D games to short stories, and pixel art games to haikus: it doesn't make sense and it's ridiculous.
I respect that you are passionate about the medium you choose, but what you claimed about novels and poems, as per your own words, "they are both wrong" at best. Don't generalize your personal experience to everyone else, there are kind, hardworking people out there writing novels and poems who love short stories just as much -- maybe what you need to do is to find those people instead of spewing your unwarranted anger over them.
Re: What makes code hard to read: Visual patterns of complexity (2023)
#276This is interesting. Something I long wondered about Lisp code, was how having glyphs that are angled (parenthesis) without much indentation in many cases might be difficult to read just because of the visual aspects of it. ((( (( ( Takes some staring at to figure out what's what.
This, and the prefix nature of operators. That's the primary reason every time I try to give Lisp a chance, I get turned off by the maze of parens that I have to unravel in my head, especially for long, nested calls. For Lispers, good for them on knowing how to wire their brains to read this effortlessly. For the rest of us, there's a reason why Python's syntax is so easy to read for most people.
Yeah it helps if it is properly formatted and intended to be easy to read. Style takes effort. A lot of us let emacs handle the formatting - auto indent and something like paredit to move lists around. Once you get a feel for how the tools move things it is a bit easier to predict, but even then it takes someone putting in effort to make it maximally readable.
Re: What makes code hard to read: Visual patterns of complexity (2023)
#277> Chaining together map/reduce/filter and other functional programming constructs (lambdas, iterators, comprehensions) may be concise, but long/multiple chains hurt readability This is not at all implied by anything else in the article. This feels like a common "I'm unfamiliar with it so it's bad" gripe that the author just sneaked in. Once you become a little familiar with it, it's usually far easier to both read an…
Sometimes I write code like this. Then I delete it and replace it with a for loop, because a loop is just easier to understand.
This functional style is what I call write only code, because the only person who can understand it is the one who wrote it. Pandas loves this kind of method chaining, and it's one of the chief reasons pandas code is hard to read.
Re: What makes code hard to read: Visual patterns of complexity (2023)
#278> Chaining together map/reduce/filter and other functional programming constructs (lambdas, iterators, comprehensions) may be concise, but long/multiple chains hurt readability This is not at all implied by anything else in the article. This feels like a common "I'm unfamiliar with it so it's bad" gripe that the author just sneaked in. Once you become a little familiar with it, it's usually far easier to both read an…
in the most popular languages this way of programming is hurt by the syntax.
this could be something more like
distinct
filter books .pageCount >1000
.author
Re: What makes code hard to read: Visual patterns of complexity (2023)
#279Earlier quoted context omitted.
The dig on chains of map/reduce/filter was listed as a "Halstead Complexity Takeaway", and seemed to come out of the blue, unjustified by any of the points made about Halstead complexity. In fact in your later funcA vs. funcB example, funcB would seem to have higher Halstead complexity due to its additional variables (depending on whether they count as additional "operands" or not). In general, long chains of functio…
> mainly because "fluent" chains should never be mutating their operand. I see this quite often with builders, actually, and I don't mind it so much there. FooBuilder() .setBar(bar) .setBaz(baz) .setQux(qux) .build()
everytime i see this i just would prefer a variadic function lol
Re: What makes code hard to read: Visual patterns of complexity (2023)
#280Earlier quoted context omitted.
You have literally just described the set of objects asked for: the unique authors of the books with more than 1,000 pages. I don't understand how you expect to get any simpler than that. The functional style isn't even requiring you to describe how to accomplish it, it almost verbatim simply describes the answer you're trying to get. If your entire objection is that you might want intermediate-named variables… you c…
The problem is that it's easy to overdo it. When you are writing the code, you already know what it's supposed to do, and adding a few more things to the chain is convenient and attractive. But when you are reading unfamiliar code, you often wish that the author was more explicit with their code. Not just with what the code is actually doing, but what it's trying to do and what are the key waypoints to get there. Wit…
If you're used to it, then it doesn't read like a single statement, even though technically it is. You put each call of the chain on its own line and it feels like reading the lines of regular imperative code. Except better because I can be sure that each line strictly only uses the result of the previous line, not two or three lines before so the logic flows nicely linearly.