Code Formatter Questions

[dn]

On 29/03/2021 04.42, Travis Griggs wrote:
> I've been looking into using a code formatter as a code base size has grown as well as contributing developers. I've found and played with autopep, black, and yapf. As well as whatever pycharm has (which may just be gui preferences around one of those 3).
> 
> I have 2 questions:
> 1) Are there any major other formatters that I can/should look at? I see some "online" pretty printers, but I'm after something I can run on whole recursive directories of code.
> 
> 2) I use more and type annotations (at least at the trivial level). But I like to have variable annotations tightly bound to the identifier, kind of like a subscript. So I want to see 
> 
>   def foo_bar(baz:int) -> bool:
>     yak:str = 'howdy mates'
> 
> And NOT 
> 
>   def foo_bar(baz: int) -> bool:
>     yak: str = 'howdy mates'
> 
> In other cases though (dictionaries for example), I'm fine with (and prefer) the spacing.
> 
> Is there anyway to make any of these formatters do this?
> 
> We write a lot of Swift and Kotlin as well as which uses the same general syntax (identifier:Type) for type annotation, and we'd like to have some consistency across the styles (we pack the couplets in those two).


Like you, I've found the ability to add such functionality to PyCharm,
VS-Codium, SublimeText (and others) useful. Such has undoubtedly
improved code-presentation.

However, there will always be differences in what I like to see, and
anyone/everyone else. Because I'm used to working in multiple
human-language/cultures, I extend similar courtesies and 'survival
tactics' into the coding world. If we're working-together and you
prefer/demand something be done in a particular way, ...

This is one reason why I like competent editor software. Let's take the
spaces/tab debate. (No, not an invitation to start that again!) It is
solved very quickly by the use of my editor's command to convert one
into the other. QED, and any frustration/anger/objections dissipate!


Sadly PyCharm is not on this machine. However, if memory serves, I have
it set-up to run checks across the entire project at every git-commit.
Any 'failures' are then reported and can either be accepted or the
commit postponed until such time as compliance with the machine's
bidding is achieved. (this may not be exactly what Q1 requires)


In some checkers (wish I could remember which), it is possible to turn
'off' certain 'complaints'. For example

def foo_bar ( baz:int ) -> bool:

might attract criticisms for the spaces outside the parentheses AND for
those immediately-inside. I agree with the former, but turn-off the
latter warning/grumble/complaint/reminder (because the inner-spaces aid
my ageing eyes).

Sadly, this informing of questionable/erroneous-formatting is somewhat
the opposite of your asking for something to *perform* a re-format.


Additionally, Q2 may require an ability to add rules to the checker.
I've not looked at such, but comments in "Auto formatters for Python"
(https://www.kevinpeters.net/auto-formatters-for-python) use phrases
such as "The tool will also do small additional checks" and
"configurable in a lot of ways" - which may/not coincide with the Qs.


Bulk re-formatting implies risk - unless you also have 100% 'bulk' and
automated testing!


Moving from one language to another can play mind-games with us. What
makes sense in one; may be right, OK, or possibly even plain-wrong, in
another. For (obvious) example, Python is unusual in that (in some
places) horizontal-spacing is a part of the language, but quite optional
in others. Accordingly, trying to generalise horizontal-formatting is
probably creating hoops-to-jump-through. Such may have been worthy of a
stereotypical (and much vilified) 1960s civil service; but not of
someone with expertise in modern programming languages. Embrace diversity!
-- 
Regards,
=dn