Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What makes code hard to read: Visual patterns of complexity (2023)

seeinglogic.com

Post reply on HN
Print view View original

101–110 of 383 posts

Re: What makes code hard to read: Visual patterns of complexity (2023)

#101

Post by WillAdams »

mbarbar_ wrote: post #95
WillAdams wrote: post #56

Earlier quoted context omitted.

The Axiom computer algebra folks seem to manage well --- I'm pretty sure that's the largest publicly available literate program which is available for inspection. I've been working to maintain a list of Literate Programs which have been published (as well as books about the process): https://www.goodreads.com/review/list/21394355-william-adams... I'd be glad of any I missed, or other links to literate programs. The l…

Another not on the list is Scheme 9 from Empty Space. I can't speak to its quality though as I've never looked at the resulting book, just perused the stripped source a little a while back. https://www.t3x.org/s9fes/

Thanks! I've added that to the list.

I'd be grateful of any other such texts.

Re: What makes code hard to read: Visual patterns of complexity (2023)

#102

Post by closed »

memhole wrote: post #87
snitzr wrote: post #58

Shoutout to the pipe operator in R. The code equivalent of "and then." It helps to unnest functions and put each action on one line. I know R is more for stats and data, but I just think it's neat.

For anyone interested in this as design, it’s called method chaining.

I think piping and method chaining are a little bit different.

Piping generally chains functions, by passing the result of one call into the next (eg result is first argument to the next).

Method chaining, like in Python, can't do this via syntax. Methods live on an object. Pipes work on any function, not just an object's methods (which can only chain to other object methods, not any function whose eg first argument can take that object).

For example, if you access Polars.DataFrame.style it returns a great_tables.GT object. But in a piping world, we wouldn't have had to add a style property that just calls GT() on the data. With a pipe, people would just be able to pipe their DataFrame to GT().

Re: What makes code hard to read: Visual patterns of complexity (2023)

#103

Post by fauigerzigerk »

slevis wrote: post #79

Do people really really agree with "Shorthand constructs that combine statements decreases difficulty"? The author even identifies a problem with the example from the original guide.

>The author even identifies a problem with the example from the original guide

He does, but I'm not sure he's right. The code snippet appears to be in C# or Dart and neither has undefined.

Re: What makes code hard to read: Visual patterns of complexity (2023)

#104

Post by russelg »

morning-coffee wrote: post #72

> These metrics definitely are debatable (they were made in the 70’s…) What is it about a decade that makes contributions produced thereabout "debatable"?

I believe their point is less about the specific decade, but rather they were made over 50 years ago.

Re: What makes code hard to read: Visual patterns of complexity (2023)

#105

Post by moi2388 »

I find the main problem is not wanting to split up functions.

I greatly prefer small helper functions, so that a more complicated one becomes more readable.

Even declaring a little local variable which explains in English what the condition you’re going to test is supposed to do is greatly appreciated

Re: What makes code hard to read: Visual patterns of complexity (2023)

#106

Post by quinnirill »

andybp85 wrote: post #50
zwnow wrote: post #28

Earlier quoted context omitted.

I consider code bad if it takes more then 5 seconds to read and understand the high level goal of a function. Doesn't matter how it looks. If its not possible to understand what a function accomplishes within a reasonable amount of time (without requiring hours upon hours of development experience), it's simply bad.

for the codebase i work on, i made a rule that "functions do what the name says and nothing else". this way if the function does too much, hopefully you feel dumb typing it and realize you should break it up.

Then what does the function that calls the split functions get called? foo_and_bar_and_qoo? And if they’re called only under some conditions?

Re: What makes code hard to read: Visual patterns of complexity (2023)

#107

Post by ajross »

necrotic_comp wrote: post #92
ajross wrote: post #38

Earlier quoted context omitted.

> I consider code bad if it takes more then 5 seconds to read and understand the high level goal of a function. That's something that's possible only for fairly trivial logic, though. Real code needs to be built on an internal "language" reflecting its invariants and data model and that's not something you can see with a microscope. IMHO obsessive attention to microscope qualities (endless style nitpicking in code re…

I agree with this up to a point - having consistent code style with some sort of formatter (gofmt, black, clang-format) goes a long way to reducing complexity of understanding because it unifies visual style. I suggest that a codebase should read like a newspaper. While there is room for op-eds in the paper, it's not all op-eds, everything else should read as a single voice.

> While there is room for op-eds in the paper,

My experience is that projects which value code formatters (and similar rulemaking) tend strongly not to have room for "op-eds", FWIW. And conversely the code bases I've seen with the best/cleanest/most-clearly-expressive code tend strongly to be the ones with fewer rules.

I think the one exception there is in some open source contexts (Linux is the archetype) which receive a fire hose of submissions of questionable quality and maintainership. There, you can use adherence to arbitrary rules as a proxy measurement[1] for attention and effort on the part of the submitter. And that I have no problem with.

But the actual value of code formatters is IMHO extremely low in practice, and the cost isn't "high", but is non-trivial.

[1] The "No Brown M&M's" trick.

Re: What makes code hard to read: Visual patterns of complexity (2023)

#109

Post by feoren »

> 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 and write than any of the alternatives. I challenge anyone to come up with a more readable example of this:

    var authorsOfLongBooks = books
        .filter(book => book.pageCount > 1000)
        .map(book => book.author)
        .distinct()
By almost any complexity metric, including his, this code is going to beat the snot out of any other way of doing this. Please, learn just the basics of functional programming. You don't need to be able to explain what a Monad is (I barely can). But you should be familiar enough that you stop randomly badmouthing map and filter like you have some sort of anti-functional-programming Tourette's syndrome.

Re: What makes code hard to read: Visual patterns of complexity (2023)

#110

Post by horsawlarway »

ikrenji wrote: post #100
jacobr1 wrote: post #39

Earlier quoted context omitted.

There is a call-stack depth problem here that is specific to codebases though. For one familiar with the the conventions, key data abstractions (not just data model but convention of how models are structured and relate) and key code abstractions, a well formed function is easy to understand. But someone relatively new to the codebase will need to take a bunch of time switching between levels to know what can be assu…

the purpose of the function should be clear from its name. if its too complex to convey this information it should have a docstring that clearly explains what it does. it's not rocket science

Names are jargon. They are themselves their own form of complexity, and they require a similar timeline to become acquainted with.

Further - the more of them you need (call depth) the worse this problem becomes.

Post reply on HN