char*M,A,Z,E=40,J[40],T[40];main(C){for(*J=A=scanf(M="%d",&C);
-- E; J[ E] =T
[E ]= E) printf("._"); for(;(A-=Z=!Z) || (printf("\n|"
) , A = 39 ,C --
) ; Z || printf (M ))M[Z]=Z[A-(E =A[J-Z])&&!C
& A == T[ A]
|6<<27<rand()||!C&!Z?J[T[E]=T[A]]=E,J[T[A]=A-Z]=A,"_.":" |"];}
[1] https://tromp.github.io/pearls.html#mazeWhen code is a maze, smart developers make maps (2025) (medium.com)
tromp an hour ago
ghgr 18 minutes ago
If, like me, you're trying to compile it, don't forget to set the
-std=gnu89
flag in gcc, so: gcc -std=gnu89 -w -o maze maze.c
Then run it as: echo 10 | ./mazejorisw an hour ago
> In code, comments are our signposts
No. Naming and good architecture are. Intuitive folder trees. Concise docs. Clear separation of concerns such that naming can suffice.
The more comments you need to ‘map’ your code, the worse of a job you’ve done.
pyrale an hour ago
You don’t choose what your forebears have written, though.
jorisw an hour ago
stingraycharles 20 minutes ago
Tade0 an hour ago
Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
I ask them to write comments in ASD-STE100 Simplified Technical English, but all I really get from that is tersness.
Also the other day I stumbled upon a huge pile of documentation and I'm still trying to figure out if it's human or machine written. I stopped reading it half way through as I figured that perhaps it wasn't written for humans to read.
rootlocus 38 minutes ago
TeMPOraL 29 minutes ago
Well, my LLMs are "smarter" than yours. They'll describe why the code is there. They'll even try to keep these comments in sync with code as it makes changes.
This includes describing the "why" behind the change even on code affected only accidentally, e.g. by reformat or reindent. And, if it wrote some code and then later learned half of it is wrong, it'll remove the offending parts and leave comments telling what used to be there, and why it isn't anymore.
Same for commit/PR messages.
May or may not be related to a recent tendency in Opus/Fable models I noticed, to eagerly turn user feedback into rules, self-correct by adding more rules, and then when some rule fails, correct it by adding a counter-steering rule - accumulating rules until eventually getting lost in them.
onion2k 17 minutes ago
I wonder if that's actually useful for an LLM though. It's additional context that should steer the LLM not to change the code to do something else.
jarofgreen 2 hours ago
Disagree. Personally that sounds like a massive barrier to reading the comment to me. Limited width column text is generally regarded as easier to read, make your comments easier to read. Especially as I probably have the code open in a limited width window, as that's what I expect from code.
dozerly 2 hours ago
verdverm 2 hours ago
Lindby 2 hours ago
Cockbrand an hour ago
This is a bit like vim vs Emacs - everyone should be able to use their favorite setup, and the formatting should not get in the way of the engineer's preferences.
ezrabuenk an hour ago
tacomagick an hour ago
xboxnolifes an hour ago
jarofgreen an hour ago
Personally, I would have hoped by 2026 we had better IDE's and tools for managing code in text files such that developers with different preferences for a number of characters in a column or things like how you display comments can be accommodated. Yet still teams end up arguing about what standard to use.
someothherguyy 2 hours ago
jarofgreen an hour ago
someothherguyy an hour ago
there are also extensions for vscode that do this, vim plugins, etc
lintfordpickle 19 minutes ago
There are also a couple of 'pointless' statements in the article itself:
> "Use a combination of in-line and standalone comments, depending on the situation"
isn't that just every kind of comment?
monster_truck an hour ago
jdw64 an hour ago