[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questionable "cosmetic changes" commits
From: |
Bengt Richter |
Subject: |
Re: Questionable "cosmetic changes" commits |
Date: |
Thu, 3 Dec 2020 04:16:24 +0100 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hi Ryan, Mark, et al,
On +2020-12-02 20:13:56 +0000, Ryan Prior wrote:
> Hi Mark!
>
> On December 2, 2020, Mark H Weaver <mhw@netris.org> wrote:
> > We all have our own personal preferences of how best to indent scheme
> > code, but if more of us adopted the habit of needlessly reordering
> > fields and reindenting code of every package we touch, as one of us
> > seems to have done, it could get out of hand quickly.
>
> I don't particularly hold any opinion about stylistic commits except
> that I prefer tools like gofmt, Python's Black and standard.js which
> enforce uniform code style, and would use such a tool for my Guile code
> if it exists.
Agree.
As Tobias points out, it exists inside emacs. But I like small independent
tools for specific things. Especially if they compose well.
>
> I do think it's important to acknowledge that the commits written by
> Raghav were part of his internship and advised by his mentors who signed
> off on the commits, so it's not like these changes were unsolicited and
> materialized out of nowhere.
I find myself with schizophrenic sympathies here :)
On the one hand:
1. Don't make unnecessary work for me.
2. If it ain't broke, don't fix it.
3. Mother appreciates help in the kitchen, but
don't touch the fine crystal! (Mother: "That's precious,
from your great grandmother, only for special occasions.
You know what cut glass crystal like that is worth?"
Smarty Kid: "Buying or selling?" :)
4: At work, sign for janitorial services: DO NOT MOVE
ANYTHING ON MY DESK!! (arrangement of untidy mess encodes
part of my workflow state).
On the other hand:
1. I habitually use emacs scheme-mode indenting as well as
shell-script-mode,
and find it a useful lens to reveal the meaning of the code, and my
errors.
2. I prefer to read pretty-printed code, and wouldn't mind if all
submitted code automatically were canonicalized in a well-defined way.
I use emacs indenting because it is right there when I am editing.
3. NOT to canonicalize can obscure dumb errors, and that can be a
smokescreen for worse.
4. For code, it is the abstract syntax tree that matters (in telling the
machine
what to do), not cosmetics, but cosmetics matter in making info
human-sensible.
In conclusion:
1. I want the best of all worlds, so I always like to pick a la carte,
unless the Chef is three-flowers-plus, or I am budget-constrained.
2. I lean towards wanting a standard pretty-print canonicalization, if it
doesn't make work for me ;)
3. diff has options to ignore white-space differences, etc., so I wonder
what tools need what options
to ease Mark's pain, (until everything is canonicalized, when that pain
should disappear anyway).
4. Canonicalization should actually help make reviewing easier, and more
effective, IWT.
5. I would like better factoring of functionality, so that e.g. I wouldn't
have to start emacs
(I know, some never leave :) to canonicalize a file the way scheme-mode
does. Unix philosophy?
(E.g., don't give cat a new built-in option like -nA, but realize how
easily it could compose with a factored-out
scheme-source canonicalizer. Some of you could probably write a bash
script to use emacs as a filter,
but is that a sensible way to go? Probably, if you are a fluent hacker
and you need a tool in a hurry,
but not for deciding separate and separable distribution components.
(I think I got my nostalgic ideas of components from Meccano kit from
the '40s ;)
tl;DR:
1. I vote for running all code to be submitted through a standard
pretty-printing canonicalizer.
It could even inject TODO stubs for missing synopses, and doc strings (as
an option :)
--
Regards,
Bengt Richter