Paid subscribers have been getting finished tidyings, 2-3/week. They are almost complete, so I wanted to recap what’s out there & ask for suggestions about what to write next. The overall outline of TF? is: Tidyings—simple acts of software design that enable change.
I have another tidying at the tip of my tongue, but I'm not really sure how it works. I think the key is Sequencing. Sometimes code is all intermingled because someone wanted to make it "efficient", and I find that if I ignore "efficiency" and order the code in a clear, sequential, chunked manner, it's easier to read and obvious inefficiencies stand out for better improvements. This probably sounds vague. I'll see if I can find an example.
I had probably read about "data dependency" when I did this, since it was mentioned in the commit message (see https://en.wikipedia.org/wiki/Data_dependency). I think it's interesting that disassociating operations from a particular order makes the code both easier to read, compile and execute.
Hello Kent, as programmers we read a lot of code. We also read a lot of logs produced by these programs. The attention to the readability/consistency/correctness/… of these logs is often overlooked. Wouldn’t it be something worth tidying ?
I was just thinking that we should invest some effort in making the life of the log reader (not necessarily a programmer BTW) easier. This log reader can be the programmer trying to remember/explore what the program actually does. It can be as simple adding some spaces, separation... Taking care of avoiding the log to lie (when it unsyncs from actual code)... Set the right level of logging to avoid being blinded by the quantity of information, …
1- remove noise. Get rid of logs that used to be useful, logs of low-level infrastructure components, ... the goal is to have (as much as possible) only the meaningful logs for the current activity
2- be consistent with information displayed (avoid "will do ..." and replace with "Here is the current state", ...)
3- plain stupid formatting effort: elegance always helps ;-) what is clearly displayed right after deployment will be easier to understand for the people in charge of maintenance (and yes bugs happen or weird behaviours must be explained to end users)
Anyway, my 2 cents. Thanks for your continuous work in making ours more interesting !
I like all those. They are a little different than the tidyings in TF? in that they change the behavior of the code to eliminate noise & increase SNR. I hope you write them up. I'm glad to promote what you write on this mailing list.
I'm interested in the friction/tension when cohesion runs into language barriers or other environmental obstacles. Say we'd want to move some code to increase cohesion, but it would need to move from e.g. JS to Python, or whatever the frontend/backend divide is. There's a whole world of interesting problems there, e.g. FFI, code generation, API protocols, etc. It's a pretty big step up from in-language tidyings, however.
I have another tidying at the tip of my tongue, but I'm not really sure how it works. I think the key is Sequencing. Sometimes code is all intermingled because someone wanted to make it "efficient", and I find that if I ignore "efficiency" and order the code in a clear, sequential, chunked manner, it's easier to read and obvious inefficiencies stand out for better improvements. This probably sounds vague. I'll see if I can find an example.
An example would be great. What you're describing sounds like Reading Order to me, so I'd like to know how what you are talking about is different.
It took me a while, but here's a reduced example from the real world: https://github.com/kimgr/data-dependency-example-python/commits/simpler.
In particular this commit, https://github.com/kimgr/data-dependency-example-python/commit/b6985f6474b04846cc4309313dabe0044c5f663f, demonstrates how re-chunking makes later changes much more obviously correct.
I had probably read about "data dependency" when I did this, since it was mentioned in the commit message (see https://en.wikipedia.org/wiki/Data_dependency). I think it's interesting that disassociating operations from a particular order makes the code both easier to read, compile and execute.
I think what I'm grasping for is disentanglement to the point where it's easier to do Reading Order changes.
Hello Kent, as programmers we read a lot of code. We also read a lot of logs produced by these programs. The attention to the readability/consistency/correctness/… of these logs is often overlooked. Wouldn’t it be something worth tidying ?
Sure. I don't have experience with this, though. Suggestions?
I was just thinking that we should invest some effort in making the life of the log reader (not necessarily a programmer BTW) easier. This log reader can be the programmer trying to remember/explore what the program actually does. It can be as simple adding some spaces, separation... Taking care of avoiding the log to lie (when it unsyncs from actual code)... Set the right level of logging to avoid being blinded by the quantity of information, …
What are the tidying-like changes you make to achieve this?
some tidying changes:
1- remove noise. Get rid of logs that used to be useful, logs of low-level infrastructure components, ... the goal is to have (as much as possible) only the meaningful logs for the current activity
2- be consistent with information displayed (avoid "will do ..." and replace with "Here is the current state", ...)
3- plain stupid formatting effort: elegance always helps ;-) what is clearly displayed right after deployment will be easier to understand for the people in charge of maintenance (and yes bugs happen or weird behaviours must be explained to end users)
Anyway, my 2 cents. Thanks for your continuous work in making ours more interesting !
I like all those. They are a little different than the tidyings in TF? in that they change the behavior of the code to eliminate noise & increase SNR. I hope you write them up. I'm glad to promote what you write on this mailing list.
Hi Kent, Apologies: I forgot to answer. I will think about it, and perhaps come back to you later.
It would be great if you could write next about the relationship between power laws and tidying.
That comes in the theory section.
I'm interested in the friction/tension when cohesion runs into language barriers or other environmental obstacles. Say we'd want to move some code to increase cohesion, but it would need to move from e.g. JS to Python, or whatever the frontend/backend divide is. There's a whole world of interesting problems there, e.g. FFI, code generation, API protocols, etc. It's a pretty big step up from in-language tidyings, however.
Excellent, thorny issues. I'll address them in book 2.
I wonder if Consistent Whitespace is a tidying that bears mention, or if I'm alone in that struggle.
"Autoformat" should be a tidying.