I am in favor of pep8 guidelines. I think it makes sense to clearly see separation between words/tokens. For me uppercase is harder to read and I don’t like getting screamed at. As long as there is documentation, this can be written there correctly as you can split it like normal words (by spaces).
-feluelle Sent from ProtonMail for iOS On Fri, Feb 4, 2022 at 01:46, Daniel Standish <daniel.stand...@astronomer.io.INVALID> wrote: > How should we name, for example, an operator such as `BranchSQLOperator`? > > This operator used to be called `BranchSqlOperator` but at some point in the > past was renamed. > > Meanwhile we have SparkSqlOperator which uses the other convention. > > And we have `EmrBaseSensor`, and `EMRContainerOperator` coexisting. > > On [this SO > post](https://stackoverflow.com/questions/2853531/how-do-you-pep-8-name-a-class-whose-name-is-an-acronym) > you can find argument on both sides of the debate. > > On one side you have a quote from PEP-8: > >> Note: When using abbreviations in CapWords, capitalize all the letters of >> the abbreviation. Thus HTTPServerError is better than HttpServerError. > > On the other side you have an example like this: > >> class NASAJPL: > > vs > >> class NasaJPL > > vs > >> class NasaJpl > > By one argument, option 3 is most readable because the "tokens" are clearly > separated (i.e. nasa and JPL) -- and certainly in some IDEs this can be a > great benefit. > > And perhaps the argument for option 2 is you say "nasa" and "J-P-L" not > "nasa" and "jipple" -- in contrast with SQL where reasonable people say > "sequel" and not "ess queue ell". > > This comes up pretty regularly, and I think we ought to make a decision and > do some pre-commit work to enforce (with an exception list a la > spelling-wordlist.txt) the decision. > > So, please consider debate kicked off, and have at it. > > Thanks
