Hi Tim --

> I'm mostly in agreement with Eliot here; I don't particularly *like* the look of code done that way but I do appreciate the (relative) consistency that the heuristic provides. It is decently documented and explained, and that means one can use it sensibly.

We can (and maybe should) certainly document other formatting styles, including a discussion about vices and virtues. ;-)

Well, the biggest issue I see at the moment is that many programmers are not able to use blank lines to group related statements in a longer methods sensibly.

The issue I have with blocks starting at the beginning of an (indented) line is only a minor concern because it only makes typing and interacting with text/code snippets more difficult for me. ;-P

Yes, Shout might help. But unsupported edge-cases in formatting could become really frustrating for programmers. ;-) 

My vote still goes to a per-package formatting style supported by tools such as Shout. 

Best,
Marcel
Am 26.10.2021 01:15:45 schrieb tim Rowledge <tim at rowledge.org>:
I'm mostly in agreement with Eliot here; I don't particularly *like* the look of code done that way but I do appreciate the (relative) consistency that the heuristic provides. It is decently documented and explained, and that means one can use it sensibly.

Also, 'prettyDiffs'. If the diffs are calculated after prettyprinting then nearly all the format related differences are invisible. Maybe that helps? Try changing the preference 'diffs with pretty print' to true.

A couple of related thoughts -

Could we make Shout do the pretty printing? (Does it already?) It's analysing code anyway, and outputting the code with all that prettiness info, so would it not be a good place to do the formatting for pretty-print too?

Since Shout is now pretty well established, and so far as I can tell any plausible machine we run Squeak on is fast enough to be using it, should we not short-circuit the process whereby text is displayed and then rather quickly replaced by Shout? It was a sensible option years ago when the analysis could take enough time to be irritating, but it seems daft to double up on the rendering these days.

I notice the SHParserST80 class>>#benchmark method and on running (on the Pi 4 as usual) the figures are quite interesting -
Methods 93326
Total 13229.046ms
Average 0.142ms
Min 0.007ms 1 range(s) (ASN1InputStream>>#asCharacter)
Median 0.060ms 17 ranges (StrikeFont class>>#primitiveCreateFont:size:flags:weight:)
80th percentile 0.175ms 41 ranges (WAResponseTest>>#testStreaming)
95th percentile 0.454ms 118 ranges (Trait class>>#named:uses:category:env:)
99th percentile 0.999ms 217 ranges (PBPreferenceView>>#offerPreferenceNameMenu:)
Max 217.314ms 128595 ranges (StrikeFont class>>#dejaVuSansBold13Data)
So the very worst case is still barely 10 frame cycles and the 99th %ile level is under 1mS, on the slowest likely host machine.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Hex dump: Where witches put used curses...



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211026/46526501/attachment.html>