Refactoring Clojure

The first thing I would do would be to take some of the inner forms and turn them into functions (single responsiblity). This isn't even Clojure-specific.

Lots of little, simple functions, composed... You can still use the threading at a higher function, but instead of doing the actual work at each step in the pipeline, you call a well-named function which does what that step was doing. Yes, it may feel redundant, but it absolutely improves human comprehension because it reads like clear human instructions.

Tests become much simpler too.

The only two challenges I face with this approach is 1 - naming things, and 2 - organizing. The function names tend to become quite long, since they ideally describe what the function does.

I haven't done this lately, now that the AI tools have become pretty great; I can imagine that an AI tool would be an excellent knowledge base for these many functions, and it would probably be very successful in providing additions or modifications given the clean, clear function names and brief contents.

I’ve been writing a lot of functional lisp lately for the first time and one thing that’s struck me is how easy it is to refactor. Because a form can always be reduced to its result, you can pluck them out, move them around, and evaluate them at any level of the tree. While this is true of functional programming in general the structure of lisp makes its super easy in a way it’s not in a Haskell or just functional JavaScript.

Seems fair, but refactoring is generally tricky and:

1) replacing a func with a simpler recursive func may or may not be ideal.

2) this fills me with no joy when I read it:

> It seems easier to start from scratch as opposed to refactor it. The characterization tests above will help ensuring that the returned hash map stays the same.

Its enormously hmm… what word to use. Ambitous? Foolish? Brave?

Anyway, taking code, writing some tests for it and then rewriting the entire thing so it passes the tests you wrote only barely falls into “refactoring”.

If anyone refactored my code base by simply rewriting from scratch the parts they dont like, I would be upset.

Rewriting things is hard, and its … brave… to think you can just write a few tests and then if they all pass its all good!

That only works in very trivial examples, and really, doesnt show case the strengths of clojure at all.

First few comments are nothing but shallow {rem,sn}arks on the formatting of the site, by users that don't even have the excuse of being recent joiners. If this is how we lead by example then it's no wonder why the quality of content+comments on this site are (imo) on the decline.

In general, it's a dream to test and refactor Clojure IMHO. Working with mostly static top-level functions, immutability by default, and mocking when necessary with the use of "with-redefs" makes writing tests easy. Also, the immutability makes it hard to break shared copies of memory which seemed to plague my earlier tangos with large Java code bases and standard OOP practices.

Usually the controversial decision for Clojure code highlighting is rainbow parens. This color scheme is horrific and unreadable (on mobile at least).

> Our mission is to take this code and make it readable

You failed. Between the unreadable text colors and the word wrap, the code is incomprehensible. I cut and pasted it into a plaintext notes app and it was way easier to understand

It's kind of funny that this article starts by showing a completely unreadable code snippet, but not because of the code, but because of the syntax highlighting scheme. There is no version of that code, or any code for that matter, that is readable using that color scheme.

[dead]