This post very nicely summarizes what I now realize I have been doing subconsciously all the time. Writing in paragraphs with headings, turning short else branches in guards, refactoring "sharp saw teeth" etc. Good to know that others also use these heuristics.
The Shapes of Code
11–20 of 71 posts
Re: The Shapes of Code
#12While the patterns themselves are interesting, the idea that all code must be rearranged in to smaller functions to be “refactored” seems a little juvenile.
It seems antithetical to the intent of "Goto considered harmful": > My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic proce…
Functions can be inlined by the compiler if it thinks it's an issue. I think it's rather a question of readability : sometimes if a process involves a long series of step I like to be able to read them linearly rather than jumping back and forth to sub steps. I can read just the headers if they're cleanly organized by cleanly separated paragraphs (with braces if needed to indicate separate scopes and no leaking variables between paragraphs).
Re: The Shapes of Code
#13Functional code would be totally different, I guess.
Probably. This is my experience with the case of the unbalanced if.
When it happens to me in Python or Ruby, I return immediately from the smaller branch and move the other branch out of the if, to the main level.
When it happens in Elixir... It doesn't happen because I don't use ifs there. I write two versions of the same function. One matches the condition for the then branch, the other the condition for the else one.
Re: The Shapes of Code
#14I'm glad I'm not the only one who pays attention to this. This is completely unsubstantiated and coming from a relatively inexperienced programmer, but it's been my experience that better code tends to produce nicer shapes. An obvious example not mentioned in the article arises when code is nested too deeply and too thinly, creating jarring and disproportionate peaks.
Microsoft's docs have an interesting idea of what good nesting looks like: https://docs.microsoft.com/en-us/previous-versions/windows/d... Apparently 13 different indentation levels is good.
wow.
Re: The Shapes of Code
#15I'm glad I'm not the only one who pays attention to this. This is completely unsubstantiated and coming from a relatively inexperienced programmer, but it's been my experience that better code tends to produce nicer shapes. An obvious example not mentioned in the article arises when code is nested too deeply and too thinly, creating jarring and disproportionate peaks.
Microsoft's docs have an interesting idea of what good nesting looks like: https://docs.microsoft.com/en-us/previous-versions/windows/d... Apparently 13 different indentation levels is good.
I actually find that surprisingly readable, probably because of the indent size which clearly allows the eye to see the blocks - and the size of my very large monitor - but this code seems to indicate a religious dogma about avoiding early returns, which would otherwise straighten it up.
Re: The Shapes of Code
#16Earlier quoted context omitted.
Microsoft's docs have an interesting idea of what good nesting looks like: https://docs.microsoft.com/en-us/previous-versions/windows/d... Apparently 13 different indentation levels is good.
I actually find that surprisingly readable, probably because of the indent size which clearly allows the eye to see the blocks - and the size of my very large monitor - but this code seems to indicate a religious dogma about avoiding early returns, which would otherwise straighten it up.
Refactoring it effectively needs some sort of scope guard, too, to run `pfd->Release();` and the like. It's just as much dogma to write C++ like C, avoiding RAII.
Re: The Shapes of Code
#17My favorite name for a shape of code I've heard is the "pyramid of doom" caused by excessive nesting- think lots of ifs or callback hell in something like node.js It's easy to recognize, and the importance of recognizing it is right in the name.
Luckily we have async await to save us!
Re: The Shapes of Code
#18I used to push hard for my favorite indentation style, and at one point I figured out that a big reason I could find bugs so fast was that, given reasonable formatting, I could see code smells just from the shape.
If the bug wasn’t in the ugliest part of the code, then that code likely had two bugs in it.
Re: The Shapes of Code
#19While the patterns themselves are interesting, the idea that all code must be rearranged in to smaller functions to be “refactored” seems a little juvenile.
There’s an exercise for creative writing that my lit major friend told me about. You take everything you’ve written and cut it up into sentences. You just push the sentences around until something clicks and you figure out how to write your way out of the “stuckness”.
Refactoring has rediscovered this trick, among others.
Re: The Shapes of Code
#20For me I would think of the "shape of code" as an abstract measure of complexity [0]. More text might correlate with more complex logic. This is a measure in a language which manipulates state / control flow.
I'm not sure what happens in a functional language. Maybe you could just think about numbers of functions. In Haskell sometimes it helps to write things in a pointfree way and you can spot some more general function to replace some noise.