Hi all!

> If you want me to follow to the formatting guidelines in Compiler & Co., I would appreciate it that you do so in Morphic & Co.

+1. Even if we decided to change coding styles for a package, enforcing such a change through an unrelated patch would not be the right way to do it IMHO.

Eliot, can we maybe agree that there is not one "best" coding style but everyone of us might have a different preferred reading/writing style? For instance, I know about and understand Kent Beck's formatting style, but personally, I find it harder to edit lines in blocks that start with spaces or brackets etc.

Craig, you are expressing exactly what I was feeling! IMHO serious development deverses to happen on a higher level of code artifacts than strings. But the level of this artifact type needs to be chosen with caution; for example, blank lines and the position of comments matter, which is why CompiledMethods would be too abstract.

But I am confident that a good pretty printer could indeed help us with this. Tom Beckmann et al. have started developing PoppyPrint [1] which has a few slips but overall looked very promising to me (I used it constantly with #acceptWithPrettyPrint [2] in one project over the last semester and was very delighted. No more mental overhead spent on manual formatting, yay!). For instance, it maintains blank lines correctly. Auto-formatting inside Shout also sounds interesting, but we would need a prototype first to test out the usability of "formatting as you type".

My vision regarding pretty-printers and prettyDiffs looks like this: Everyone can edit and view (Trunk) code in their images formatted in their preferred style (for which the pretty-printer provides a list of options). The underlying representation of the source code is auto-formatted according to the detected existing coding style in the relevant package, so even if the code is exchanged between two images, we would not need prettyDiffs in the commits at source.squeak.org messages.
It would be nice to realize this vision by integrating PoppyPrint into the Trunk and making it customizable, if Tom agrees with this plan.

> Since there are aspects of the underlying program theory in each module not explicable but implicit, we rely on th formatting of each module's main authors at the moment.

This is an issue for some edge cases in our codebase, but I believe that could handle these edge cases correctly in a good pretty-printer. Besides, implicit concepts are hard to grasp, so at least for new code, I would prefer to follow the Zen of Python in this regard:

	$ python
	Python 3.6.9 (default, Jan 26 2021, 15:33:00)
	[GCC 8.4.0] on linux
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import this
	The Zen of Python, by Tim Peters

	Beautiful is better than ugly.
	Explicit is better than implicit.
	...

Best,
Christoph

[1] https://github.com/hpi-swa-teaching/poppy-print
[2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215416.html

---
Sent from Squeak Inbox Talk

On 2021-10-26T09:55:27+02:00, marcel.taeumel at hpi.de wrote:

> 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>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211025/156958a5/attachment.html>