Re: Emacs rewrite in a maintainable language

[Oleh Krehel]

Tassilo Horn <address@hidden> writes:

> Przemysław Wojnowski <address@hidden> writes:
>
>>>> I don't. I have no problem spending time to replace "char const *"
>>>> into "const char *". Browsing through a code base that I want to get
>>>> familiar with and fixing a small annoyance doesn't sound bad to me.
>>>
>>> Pointless churn. Find something that fixes an bug, or adds a useful
>>> new feature, and work on that. You will find it more rewarding, and
>>> other users and developers will find your contribution more helpful.
>>
>> Refactorings that increase maintainability (like this one) are very
>> useful to other developers.
>>
>> Such changes, even small, accumulate towards something that can be
>> called a "maintainable system".  In (wannabe) healthy systems it is
>> everyday practice.
>
> OTOH, they reduce the helpfulness version control offers to new and old
> developers.  I.e., it's good when "git blame" shows you the last changes
> which actually changed the code, and switching "char const *" to "const
> char *" or vice versa are no real changes.

I've seen this excuse before. Doesn't it mean that there's a flaw in the
"git blame" workflow rather than in the refactoring commits?  Besides,
"git blame" provides a way to specify a range of revisions that you're
interested in.

Personally, looking through the revision history in order to understand
code is a last resort for me. The code should be written and documented
well enough to be understandable at the current revision. This is
further magnified by the fact that we release source tarballs, which
should be self-containing.

> In the same vein, it's of course good to have one consistent indentation
> style, one consistent style of setting braces, one consistent style of
> naming variables, etc.  But I'd suggest to clean up the non-conforming
> parts only when you do significant changes in that area anyhow.

You mean:

    /* TODO: change "char const *" to "const char *" when an opportunity arises
      to change foo */
    void foo (char const *bar);

This doesn't sound like a sustainable and healthy approach.

In the same vein, concerning the matter of one consistent indentation
style, on occasion I've received complaints of producing too large
whitespace diffs when changing Elisp functions. On those occasions I
had to twist myself into never using `indent-sexp' and inserting the
appropriate amount of mixed tabs and spaces with "C-q". It wasn't fun.

    Oleh