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 -- https://mail.python.org/mailman/listinfo/python-list
